And for the finale, you will be amazed and astounded as you watch
ActiveRecord models appear from nowhere. No class definition, just any
old database tables you have lying around the home is all you’ll need to
perform this trick!
No cover charge. No free steak knives. No heavy lifting involved.
And for the finale, you will be amazed and astounded as you watch
ActiveRecord models appear from nowhere. No class definition, just any
old database tables you have lying around the home is all you'll need to
perform this trick!
No cover charge. No free steak knives. No heavy lifting involved.
Quick question on install though... why a Gem and not a Rails Plugin?
Its really a pure extension of ActiveRecords, which can be used outside
of Rails. I think adding one line to environment.rb is quicker and
easier than installing a plugin too.
Question: Is this compatible with your previous work on composite
keys for active records?
Not yet. Currently the Composite Primary Keys solution requires an
explicit call to set_primary_keys to activate the code (like a
acts_as_... plugin). As long as I can determine from the connection
object that 2+ columns have "primary" = true then I should be able to
make that call automatically.
I will migrate my spaceship's control software to Dr. Nic's Magic models
now.
I'm only missing habtm. Is that planned? There's a Zorg meeting on mars in
two weeks, and I need to be there on time.
···
On 8/8/06, Dr Nic <drnicwilliams@gmail.com> wrote:
Kev Jackson wrote:
> Question: Is this compatible with your previous work on composite
> keys for active records?
Not yet. Currently the Composite Primary Keys solution requires an
explicit call to set_primary_keys to activate the code (like a
acts_as_... plugin). As long as I can determine from the connection
object that 2+ columns have "primary" = true then I should be able to
make that call automatically.
I will migrate my spaceship's control software to Dr. Nic's Magic models
now.
I'm only missing habtm. Is that planned? There's a Zorg meeting on mars
in
two weeks, and I need to be there on time.
I'm not convinced, earth man, that an HABTM association is really useful
if you can have a pair of lovely has_many :through's for free instead.
Tell your Zorg cohorts that for invasions in the 21st century, you'd be
crazy to settle for a HABTM if you didn't need one.
I could be wrong - I got 100 out of 200 in year 11 English so the
wizards of Australian education certainly got one up on me there - but I
think the end result of a has_many :through association will be the same
as your run-of-the-mill habtm. Let me know if there's something special
about them that I'm missing.
I will migrate my spaceship's control software to Dr. Nic's Magic models
now.
I'm only missing habtm. Is that planned? There's a Zorg meeting on mars
in
two weeks, and I need to be there on time.
I'm not convinced, earth man, that an HABTM association is really useful
if you can have a pair of lovely has_many :through's for free instead.
Tell your Zorg cohorts that for invasions in the 21st century, you'd be
crazy to settle for a HABTM if you didn't need one.
I could be wrong - I got 100 out of 200 in year 11 English so the
wizards of Australian education certainly got one up on me there - but I
think the end result of a has_many :through association will be the same
as your run-of-the-mill habtm. Let me know if there's something special
about them that I'm missing.
You don't always want a has_many :through though. Sometimes the only thing that exists is the many-to-many relationship. (A person has and belongs to many clubs for instance.)
You don't always want a has_many :through though. Sometimes the only
thing that exists is the many-to-many relationship. (A person has and
belongs to many clubs for instance.)
Just so I understand, let's play with some tables:
people =>* group_people *<= groups
The following sequence of commands should work:
person = Person.find_first
groups = person.groups
Is that how a HABTM would work too?
If so, then to emulate a HABTM, you just need to ignore the join table
in your app, and never call peron.group_people, etc.
My doubt comes from not having used HABTM since the start of the year;
but I think from the object's point of view, the HABTM and the has_many
:through behave the same to the Person object if you send it the groups
method.
Yeah they behave the same, but sometimes you don't want the overhead of creating a model just so AR is satisfied
···
On Aug 15, 2006, at 11:09 AM, Dr Nic wrote:
Logan Capaldo wrote:
You don't always want a has_many :through though. Sometimes the only
thing that exists is the many-to-many relationship. (A person has and
belongs to many clubs for instance.)
Just so I understand, let's play with some tables:
people =>* group_people *<= groups
The following sequence of commands should work:
person = Person.find_first
groups = person.groups
Is that how a HABTM would work too?
If so, then to emulate a HABTM, you just need to ignore the join table
in your app, and never call peron.group_people, etc.
My doubt comes from not having used HABTM since the start of the year;
but I think from the object's point of view, the HABTM and the has_many
:through behave the same to the Person object if you send it the groups
method.
Yeah they behave the same, but sometimes you don't want the overhead
of creating a model just so AR is satisfied
This might just be sacrifice of using the MMs. I'm not sure there's a
way to know to create just a HABTM when you might need a has_many
:through; the latter being more general and powerful. The triggering
logic would be the same.
Couldn't you just create a habtm if there are no columns in the intermediate tale but the ones with the keys? Does MM support has_one BTW?
-- fxn
···
On Aug 16, 2006, at 8:38 AM, Dr Nic wrote:
This might just be sacrifice of using the MMs. I'm not sure there's a
way to know to create just a HABTM when you might need a has_many
:through; the latter being more general and powerful. The triggering
logic would be the same.
This might just be sacrifice of using the MMs. I'm not sure there's a
way to know to create just a HABTM when you might need a has_many
:through; the latter being more general and powerful. The triggering
logic would be the same.
Couldn't you just create a habtm if there are no columns in the
intermediate tale but the ones with the keys? Does MM support has_one
BTW?
It generates a has_one if your method name is singular.
This might just be sacrifice of using the MMs. I'm not sure there's a
way to know to create just a HABTM when you might need a has_many
:through; the latter being more general and powerful. The triggering
logic would be the same.
Couldn't you just create a habtm if there are no columns in the
intermediate tale but the ones with the keys? Does MM support has_one
BTW?
It generates a has_one if your method name is singular.
A very simple and trying-to-be-completely-unmagic-but-clever ORM I've
been writing recently makes relationships based on foreign keys. If
the field referenced is declared "unique", it will be like has_one,
else like has_many. Of course, my system was made for non-legacy and
well-specified database schemata.
That's right, please stand behind the police line.
A very simple and trying-to-be-completely-unmagic-but-clever ORM I've
been writing recently makes relationships based on foreign keys. If
the field referenced is declared "unique", it will be like has_one,
else like has_many. Of course, my system was made for non-legacy and
well-specified database schemata.
Cool. I've been working on adding foreign key support (generically, but
will require per-vendor extensions) that should be released soon for the
MMs.
The "unique" idea is interesting. I'll have a think about that one.
