On Feb 18, 2006, at 3:30 PM, Michael Koziarski wrote:
I know that supporting composite keys is not a MUST, but it's a
SHOULD.
Your invoice lines will have an invoice_id relating them to the
invoice, it doesn't get much more related than that. If you're
seeing the ids as anything other than serialised object-identity, then
you're over using.
The very very very good reason not to support composite keys is that
it doesn't give any tangible benefits over single, unique IDs. Even
less so with an ORM like AR. If you want, you can add your own unique
constraints.
Unfortunately, it's beyond the control of poor saps like me who are
trying to integrate with legacy databases old enough to graduate from
elementary school. (c: All the newer tables here fortunately have
single PKs, but the older ones...not so much. Mostly we're just
reading, but occasionally we will want to save some composite PK rows.
I understand ActiveRecord doesn't support it now in favor of
simpleness, but aventually it should have that option.
It won't, for the same reasons we don't support all the other DBA
centric options. The costs outweight the benefits.
The cost being a broad, ugly increase in AR code complexity? Would a
patch ever be accepted for it, or is the ripple effect of composite
keys just too big?
OTOH, does anyone have advice for implementing this as a plugin?
Worst case scenario, I can just implement some custom helper methods
per composite key table, to save the data, but I'd prefer a more
integrated solution. The less ad hoc the better.
John
--
John R. Sheets
http://umber.sourceforge.net
http://writersforge.sourceforge.net
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
