Re: database design patterns for the desperate
Re: database design patterns for the desperate
- Subject: Re: database design patterns for the desperate
- From: Kieran Kelleher <email@hidden>
- Date: Wed, 11 May 2011 16:10:06 -0400
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