• 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: Unique attributes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unique attributes


  • Subject: Re: Unique attributes
  • From: Jeffrey Schmitz <email@hidden>
  • Date: Sat, 18 Feb 2006 15:39:39 -0600

cvxcx7gygghfhgntkjkjkgkhkjkhkkhllgklbkkhkhkhkkhkh;lhjljhkhjjh77777766567 78900987654333221` `````````````````````````````````````/////////////eyffhgfhhhh/bhg/,// n mj,k,..fhvhcghvffbbvvbbbko01111uyghhggvtggbgghyygyyyfytytytyuihhhhhhhhhh jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjuliuuhgtthg iuhghhhhhhhhhghvbnjbjbhbghhhvfhhgfgggggggggghfjjjjjjjjjjjjjjjjjjjjjjjjjj jjjjjfjtuyi y uftyyurttuyruyutyutr546tyujjyggjhhgju8yty7t8 t 4urfsghfdjsffjjgfgfgghghgfhgffwqwwsewwwswtyurioioprirprpopiooeehhhgj48hu ti4iiutyijkthkgthjhjhhbggghtfdtefrttyghgngghjhhjkkkkk
On Feb 18, 2006, at 6:44 AM, Lachlan Deck wrote:


Hi there,

On 16/02/2006, at 4:48 PM, Ian Joyner wrote:

On 16/02/2006, at 2:38 PM, Arturo Pérez wrote:

Ah, I see what you're getting at. EO does support multi-value PKs (for the join table example) but that doesn't address your point.

My perspective might be colored by my preferences and I'm just thinking out loud but...

I am a big fan of model-based fetchspecs. The code-based ones violate the "if you're writing code, you're doing it wrong" rule. As such, I believe (with no evidence to back it up) that perhaps model-based fetchspecs were intended to address your point to a certain extent.

You need alternate keys and a fetchspec would provide that. It will return EOs properly etc.

Excellent. I can see how specifying the combination of attributes to make a key for a fetch spec would do that. I'm still just trying to come up with a good pattern of usage for fetchspecs – they seem very powerful, but I don't think I've got my head around the whole thing yet, and yes I'd prefer to do a fetchspec than write code.

Both will achieve the same results. One of them is convenient visually, the other is convenient and powerful in its extensibility. The choice is yours. But really, "if you're writing code, you're doing it wrong" is overstating the convenience of visual tools. They have their limit.


Now, what won't a model-based fetch spec do?

for starters it cannot take into account application/session/ request logic. e.g., based on some condition of the request. But that doesn't make them problematic. Again, it's all about personal preference and/or the problem at hand.


Likewise, things like the external query and restricting qualifier just aren't given enough space in the visual tool to be ultimately convenient.

Anyway, back to the discussion...

You'd need to couple them to validation somehow.

I imagine you'd also want to synchronise (via transactions) your saves to the datastore. Otherwise, two session's could simultaneously do a count(*) for duplicate records already in the database, both of which could succeed - and then go ahead and save the two records. Your validation rules won't be enough.


e.g., on a single WOApp instance you could lock the datastore prior to saving. On multiple instances, however, you're cooked without database constraints. The alternative would be to wrap the database with a WOApp (e.g., a Web Service) which could synchronize the saves.

That's one thing that would need to be addressed. What are other things your mental model requires? I think redoing some of the object-uniquing EOF does based on PK would need to be redone. Anything else?

I think, what I am getting at is just the data modelling issue that is done before any consideration of queries is addressed – get the model right and then you can do very powerful ad hoc queries. Perhaps once you have your candidate keys, those could form the basis of fetchspecs?

Have a look at EOEntity's api. Specifically 'externalQuery' and 'restrictingQualifier'.
I haven't seen these get any air time on the mailing list, as far as I'm aware anyway, but they're useful. You can also set these in EOModeler.


I'm looking at some relational DB texts to figure this out (CJ Date, Introduction to Database Systems, and John Hughes Database Technology), which give formal definitions of candidate keys, along with their uniqueness and irreducibility properties, and how they relate to normalization.

Again, concurrent saves will likely be an issue without database support. I'm not sure of the best solution but there's unique constraints, stored procedures etc. Locking is another option - though if the app goes south who'll unlock the database?


Anyway, I think that rather than just adding unique to a column or set of columns that unique could be derived from a candidate key property somehow. (A candidate key being built on actual data values, rather than implementation pointers which is how primary and foreign keys are done in EO.)

I'm probably, just making things more confusing now, while trying to get at something that would simplify design issues.

It's all worth thinking about. I'd be interested in hearing about how others have solved the multiple-instance app concurrent saves where such constraints are desired (e.g., Person.username)...


with regards,
--

Lachlan Deck


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com


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
References: 
 >Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Robert Walker <email@hidden>)
 >Re: Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Chuck Hill <email@hidden>)
 >Re: Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Arturo Perez <email@hidden>)
 >Re: Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Arturo Pérez <email@hidden>)
 >Re: Unique attributes (From: Ian Joyner <email@hidden>)
 >Re: Unique attributes (From: Lachlan Deck <email@hidden>)

  • Prev by Date: Re: Most efficient character parsing.
  • Next by Date: Re: Most efficient character parsing.
  • Previous by thread: Re: Unique attributes
  • Next by thread: JSON / AJAX Requesthandler from Jean-François Veillette
  • Index(es):
    • Date
    • Thread