Re: Complex EOQualifier format
Re: Complex EOQualifier format
- Subject: Re: Complex EOQualifier format
- From: "Jerry W. Walker" <email@hidden>
- Date: Wed, 4 Jul 2007 22:44:21 -0400
Hi, Steven,
I've used the formula you described in a WO application a while back
and did all the work in Java. Basically this meant, when the
application started up, caching a table of all the geographic points
in which I was interested in three Java arrays: latitude[], longitude
[] and key[]. To do this, I made the primary key of the geographic
table a class property and used it as the key.
Using the first two of these arrays in a for loop, I could rapidly
find all the points that were within some radius of an arbitrary
latitude and longitude and would simply select the corresponding keys
(that is, table's primary keys) from the key array by index number
and add them to an NSMutableArray.
In fact, as I think back on this application, I actually stored the
found points in a Java linked list to sort them in order of
increasing distance from the arbitrary point as I found them. This
allowed me to obtain either the n closest points, or all the points
within a given radius using almost identical logic.
With the resulting list of keys, I simply fetched all the records
with those keys. I think I used Pierre Bernard's "contained in"
qualifier to fetch all the records whose keys were contained in my list.
The geographic based records in my application were sufficiently
stable that I could afford to cache them and renew the cache
periodically with a long period (actually, every time new elements
were added to the geographic table, which occurred about every other
day). The combined arrays used relatively little memory (two doubles
and a long for each geographic point) compared to trying to cache the
entire EOs that they represented.
This approach worked well for a table of several thousand geographic
points. I would start to worry and look for further optimizations if
the number of points got into the millions or greater.
Regards,
Jerry
On Jul 4, 2007, at 5:28 PM, Steven Mark McCraw wrote:
On Jul 4, 2007, at 5:15 PM, Pierre Bernard wrote:
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.
I can appreciate this, but there are times when you absolutely
cannot do your processing in Java. The example I posted earlier
(which fetches geographical points within a certain distance of
other geographical points) is a perfect example. You can do this
in the database and have a response to your users within seconds,
or you can do it in java and have a response to your users in
minutes. It would appear that the option you are left with here is
fetching raw rows.
- 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
That sounds like a neat idea, but I don't really know how you would
go about it. I downloaded your code just now and will have a look
when I have more time.
- 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
How do you create your qualifiers if not with
qualifierWithQualifierFormat?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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