Re: database design patterns for the desperate
Re: database design patterns for the desperate
- Subject: Re: database design patterns for the desperate
- From: Michael Gargano <email@hidden>
- Date: Wed, 11 May 2011 13:33:12 -0700
- Acceptlanguage: en-US
- Thread-topic: database design patterns for the desperate
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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden