Kirk Haines wrote:
[snip]
But if you start from the other end, with the objects, you are not starting
with any of that meta information, so you have to do something to identify
classes which should map to tables, and if you intend for one field to store
only objects or arrays of objects of another class which is also represented
in the db by a table, you have to do something on the ruby side to declare
that. The has_one, has_many, many_to_many, and similar terms are commonly
accepted terms for describing these relationships. In thinking a bit about
it, though, I do suppose that one need not need to actually use those terms.
I could pretty easily make the following work in Kansas today.
class Schools
# The line below would indicate that there is a one to many relationship
# between a school and the inventories. So one school can be associated
# with many inventory records.
relationship Inventories.school_idx
end
class Inventories
# This line indicates that there is a one to one relationship between
# an Inventories object (and thus, db record) and a Chemicals object.
relationship chemical_idx => Chemicals
end
Yes, but that's just giving different names to the same things, isn't
it?
If I see "relationship" in someone's code, I don't really know what it
means. I assume it's some database stuff.
As far as I can see, all that's really needed is:
1. Let each class map to a table
2. Let each table have a known unique primary key
Then we don't need all this "relationship" stuff, do we?
When I think of an object containing a sub-object (and yes, I certainly
know these are only *references* internally), I don't think "a Foo
object has a one-to-one relationship with a Bar object"; I just think
"Foo has a field bar, which will typically be a Bar." (And no, I'm not
a fan of static typing, either.)
As for a "has-many" relationship (in objects, not in DBs) -- isn't that
just what we call an "array"? The difference being that Ruby arrays are
heterogeneous whereas rows of a table all represent the same type?
Reflection could tell us that a field is an array. It could also tell
us
the type of each element in the array.
Over the yeats I've stuck thousands of arrays into thousands of
objects,
all without ever thinking about the "relationship" of the container to
the containee; the former contains the latter, that's about it. And
I've
never dwelled long on the fact that an array indeed "has many" items in
it,
or felt the need to annotate that fact explicitly.
I want to do as little specification as possible to store my objects.
That's where I'm coming from. I want the persistence framework to be as
smart as possible and make as many reasonable assumptions as possible.
I want to spend as little time coding the metadata portion as I can,
and
I want it all stuck in the same place in my code, in as few lines as
possible.
Again, I'm not criticizing your opinions or anyone else's. This is just
me. This sort of thing is as personal as the choice of variable and
method names.
I am not seeing why it would be beneficial to keep this annotation seperate
from the classes. The information has to be looked up somewhere, and if the
annotation doesn't interfere with the class otherwise, what is the downside
to having that information attached? If it is seperate, you still have to,
somehow, associate the two, and the information still needs to be looked up.
What is the benefit?
It's highly subjective. If I do reflection and look at the stuff in my
classes, I don't want to see the extraneous stuff.
Again I stress, it's just me. I'm not arguing it's *wrong* to do it the
other
way. If a class inherits from another or includes a module, then those
are more
tightly coupled than if I simply pass an object into a method of
another class
(which is the ultimate decoupling other than not interacting at all).
Hal
Read my post from five mins ago and