Re: Unique attributes
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