This one time, at band camp, Ryan McDonough said:
RM>I have an object that has two different use cases depending on the type of
RM>user that is using the object. The Object is a subscription class. In one
RM>use case, the subscription belongs to a mailing list that contains a list of
RM>subscriptions. In the second use case, the subscription belongs to the to
RM>the user and the user only needs to know what mailing list it belongs to. In
RM>my current situation, the subscription is a child of mailing list. So when a
RM>subscription is loaded independently of it's mailing list, the mailing list
RM>is automatically loaded.
RM>
RM>What I would like to do is create one subscription class for each use case
RM>but have them both mapped to the same table. Now I know that it should be
RM>possible to have two objects mapped to the same table, but I'm wondering of
RM>this a a good practice and if there are any potential issues that one should
RM>be aware of? (locking, etc.) Thanks.
Ryan,
Mapping two objects to a single table is certainly supported. However,
I haven't found this be very common as I've only seen this done in a
few projects. More often what I've seen are two different mappings for
a single class mapped to a single table. Each mapping covers a single
use case and is loaded only when needed.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev