Re: Complex EOQualifier format
Re: Complex EOQualifier format
- Subject: Re: Complex EOQualifier format
- From: Pierre Bernard <email@hidden>
- Date: Wed, 4 Jul 2007 23:15:11 +0200
I feel the urge to voice opinions about this.
- EOF is an ORM not a SQL generator. Its task is to allow you to work
in a pure OO work and make object graph management and persistent
transparent. Meaning: you want to do your processing in Java, not in
the database.
- You are free to extend EOF's magic by writing custom qualifiers. I
have some on my web site: http://www.bernard-web.com/pierre
- qualifierWithFormat() is evil. The qualifier string cannot be
validated by the compiler. You are tempted to write out attribute
names in String, thus making future evolutions of the model
difficult. It is almost like writing SQL
Pierre
On Jul 4, 2007, at 11:06 PM, Steven Mark McCraw wrote:
I can appreciate that breadth of functionality indeed, but it
obviously comes at the sacrifice of relational database-specific
functionality. It would be nice if EOF (and I guess by EOF here,
what I really mean is EOQualifier or some variant) went to greater
pains to accommodate what is (I would assume) the more widely used
case, which is interacting with a relational database at something
more than a very basic level for queries. For a second I got all
excited that EOF actually did this when I stumbled across
EOSQLQualifier, but I see that this has been deprecated. It
appears there is already some limited expansion of the
functionality in ERXEOUtilities for doing grouping, I think, so
maybe extending database specific functionality there is something
that will happen in the future. I can vaguely conceive of how to
do it using EOFetchspecification's setHints method, but don't have
time to try to prove the concept at the moment. If anyone else has
tinkered with this concept, I would love to hear about the outcome.
On Jul 4, 2007, at 4:51 PM, Mike Schrag wrote:
Apparently EOF considers even subtraction to be a database
specific task, and I guess the thought is that somehow this ruins
database independence.
It's not that it "somehow" ruins it, it just "does" ruin it. EOF
is not just database vendor independent, it's literally datastore
independent. EOQualifiers provide an abstraction on the concept
of a query language. For instance, I'm working on JavaMailAdaptor
right now, which is an EOF adaptor on top of an arbitrary JavaMail
store. You can see how embedding straight SQL into a qualifier
could be problematic in that kind of scenario.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40bluecollarsoftware.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:
email@hidden
This email sent to email@hidden
- - -
Houdah Software s. à r. l.
http://www.houdah.com
HoudahGeo: One-stop photo geocoding
HoudahSpot: Powerful Spotlight frontend
_______________________________________________
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