[eluser]tunesmith[/eluser]
Hi, say you have a datastore with an existing schema and outside existing processes writing to those tables. Meaning, there would be a cost to changing the table names. And say the table names don't fit the DMZ convention.
I saw that the models can manually override the $table name in the class definition, but in the docs this was mentioned in regard to plurals. How far does this go, is it all right to name the table something wildly different, with different caps conventions, etc?
Also, can the names of linking tables be overridden?
Finally, regarding linking tables, can we instead make them their own objects, with an overridden table name. Is there something that makes this impossible? Here's an example:
Say you have a User, and an Event. And the linking table would (conceptually) be an Invitation. An Event can have multiple Users, and a User can be invited to multiple Events. So it's a many-to-many relationship. However, the Invitation itself might have some of its own fields, like date sent, how many times its been sent out, etc. I understand that through advanced relationships it is possible to query on those Invitation-specific fields. But what if you want to query Invitations that don't have to do with Users or Events? Like, the list of Invitations that were sent in a date range, irrespective of Users and Events.
Is it valid to instead just make an Invitation model with its own relationships? Then Users and Events would have has_many of Invitations, and Invitations would just have has_one of each. And then maybe Invitation could have an overridden table name. Does that work? It seems like any time a linking table would have extra fields, one might want to consider making it its own model.
Thanks for helping me get my head around this. As you can see, I'm trying to figure out how easily DMZ can be adapted to a schema we might not have 100% control over.
