Thanks Kieran,
Maybe something I wasn't clear about either is that the local user copy
can change attributes all the way across the structure. So, tB and tC will
have additional attributes as well and local values for attributes there too.
So, I understand doing that for tA, I guess I would need to have the same
procedure for tB and tC and the implementation of the EOCopyable interface
would have to create the local versions of the tB and tC objects when doing the
deep copy.
This is definitely an option. I'm not expecting it to be pretty.
My heart grows heavy with foreign key constraints.
-Mike
On May 11, 2011, at 4:10 PM, Kieran Kelleher wrote:
> And to add to that, if it's not clear ......
>
> - Use the same table (as you said "near identical")
> - If you like prefix the non-common attributes with underscore or sth, and
> write behavior interface cover methods that throw when the attribute is being
> set on the wrong type.
> - Use type attribute for fetches to exclude user-customized templates.
>
>
> On May 11, 2011, at 3:56 PM, Kieran Kelleher wrote:
>
>> If I understood you correctly:
>>
>> - Make option relationship from tUser <-->> tA for "user-owned templates"
>> - Add extra fields to tA
>> - Add a type field to tA - Integer - each int denotes a behavior
>> - Use Strategy Design pattern and create 2 behavior classes that correspond
>> to two templates types
>> TemplateBehavior interface
>> DefaultTemplateBehavior
>> UserTemplateBehavior
>>
>> - Methods/logic that differ between both template scenarios should be put in
>> the Behavior interface and implemented in Behavior classes.
>> - The EO class corresponding to tA also implements TemplateBehavior
>> interface.
>> - Set default value of type to be DefaultTemplateBehavior type (say type =
>> 10)
>> - lazy instantiate behavior in the class based on value of type.
>> private TemplateBehavior _behavior;
>>
>> private TemplateBehavior behavior() {
>> if ( _behavior == null) {
>> if (type().intValue() == 20) {
>> _behavior = new UserTemplateBehavior(this);
>> } else {
>> _behavior = new DefaultTemplateBehavior(this);
>> }
>> }
>> return _behavior;
>>
>> - implement interface methods in the EO class like this
>> public void doSomething() {
>> behavior().doSomething();
>> }
>>
>> - Use Chuck's EOCopyable interface and utilities to copy tA instance when a
>> user wants to customize. Set your extra attrivutes and change the type of
>> the copied template to the int corresponding to the UserTemplateBehavior
>> (and reset _behavior to null - I have a reset() method in my GenericEO and
>> is used to nullify cached ivars on every didUpdate and didInsert btw)
>>
>> HTH, Kieran
>>
>> On May 11, 2011, at 3:14 PM, Michael Gargano wrote:
>>
>>> I was just talking to David Holt about this and he suggested I tap the
>>> brain trust. :)
>>>
>>> I was wondering if there is a database design pattern for a situation where
>>> I have some template structure
>>> let's say
>>>
>>> tA <->> tB <->> tC (records across these tables are the template, the
>>> template is a whole object graph rooted at one record in tA)
>>>
>>> where the templates can be configured on a per tenant basis (so, the
>>> templates themselves are records that define defaults and new ones can be
>>> added when new tenants or templates are added). I need to make a copy of a
>>> template that a tenant uses and make it local to a user (under that tenant)
>>> who can then customize the values in that template for their needs.
>>>
>>> It's basically a class/instance kind of structure, but at the data level in
>>> the database. It's as if I need to copy an EOs from one table to another
>>> where the destination table has a few more attributes than the source table
>>> did. It's made more complicated by the fact that I need to copy that
>>> template object graph, not just one EO.
>>>
>>> Any suggestions?
>>> *Hopes beyond hope*
>>>
>>> Thanks.
>>> -Mike
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com
>>>
>>> This email sent to [email protected]
>>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
