• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: database design patterns for the desperate
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: database design patterns for the desperate
      • From: Michael Gargano <email@hidden>
References: 
 >database design patterns for the desperate (From: Michael Gargano <email@hidden>)
 >Re: database design patterns for the desperate (From: Kieran Kelleher <email@hidden>)

  • Prev by Date: Re: database design patterns for the desperate
  • Next by Date: Re: database design patterns for the desperate
  • Previous by thread: Re: database design patterns for the desperate
  • Next by thread: Re: database design patterns for the desperate
  • Index(es):
    • Date
    • Thread