• 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: Best Design Practice
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best Design Practice


  • Subject: Re: Best Design Practice
  • From: Chuck Hill <email@hidden>
  • Date: Wed, 12 Apr 2006 17:12:22 -0700

Owen,

I think you are mixing up EOF operations and making this more complex than it needs to be. Let me see if I can simplify it.


On Apr 12, 2006, at 4:59 PM, Owen McKerrow wrote:

Say you go to the database not realizing that the objects are already cahced, does WO then just do the sort and filter on the these cahched objects in memory ?

Let's hold off on this for a minute. I think this gets answered below.


What happens if you have 1/2 the objects in memory and the other 1/2 still need to be retrieved from the DB ?

I am assuming here that you are talking about the method where you are using a fetch spec. EOF will turn the fetch spec into SQL, and return all the _data_ for the rows matching your qualifier, sorted as you have indicated.


Who does the sorting and filtering then?

The database does, this never changes if you are using a fetch spec with a sort ordering.



I would assume that if the cached objects are still considered "fresh" by WO then it would get the other objects from the DB and do it in memory.

Now you are losing me. If you use a fetch spec, it goes to the database. Period.



Otherwise it would have to update the objects it already has in memory, with the ones returned from the DB.

If it is not a refreshing fetch and the snapshot is not stale, EOF will discard the returned rows. What it will keep is the order that the primary keys came back in so that it can give you an array of EOs sorted in the order that you asked for. If data comes back for objects not in the cache, EOF will create snapshots for those objects. If the snapshots are stale or the fetch marked as refreshing, EOF will refresh the snapshots.


And does this apply no matter how many objects are cached.

Yes.

Say you have 1 object cached, what happens then ? Indeed how does WO know that one of the requested objects is already in cache ?

It does not care. You asked it to go the the database and it does so. It may discard 100% of the data returned and only keep the order of the objects if all the snapshots are in memory and up to date. For objects already in memory, fetching is an expensive way to get a reference to them.



Does it apply you query against the EODatabaseContext ( I think thats the one that stores the snapshots and stuff ) before going to the DB ? Or does it always go to the DB ?

It is not so fancy as that, it always goes to the database.


Chuck



On 13/04/2006, at 9:25 AM, Sacha Michel Mallais wrote:

On Apr 12, 2006, at 4:09 PM, Owen McKerrow wrote:

I have been using the first method but after talking with a college yesterday Im wondering if the second way may be quicker.
The in-memory will stil require a trip( or several to the DB ) to get the position sets, and then have to do the sort in memory once they get back. But if I have set the relationships Batch Faulting size, would these objects not already be in memory and thus we then cut down on the trip to the DB ?

It really is dependant on the state of your object store. If you have to go to the database to get the data, sorting at the database will almost always be preferable, particularly if you have an index on the sorted column (which turns sorting from O (nlogn) to O(1)). However, if your objects are already in memory, sorting in memory will almost always be preferable, simply because going to the database is expensive. With a large dataset (10s of 1000s of rows at least) in which you only intend to show the first few rows, you're almost always better off going to the database because sorting time will overshadow communication time with the database...


HTH,


sacha


-- Sacha Michel Mallais 800 kg gorilla Global Village Consulting Inc. http://www.global-village.net/ PGP Key ID: 7D757B65 AIM: smallais 1. Never tell everything at once. -- Ken Venturi, Ken Venturi's Two Great Rules of Life




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


This email sent to email@hidden

--
Coming in late 2006 - an introduction to web applications using WebObjects and Xcode http://www.global-village.net/wointro


Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects




_______________________________________________ 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: 
 >Best Design Practice (From: Owen McKerrow <email@hidden>)
 >Re: Best Design Practice (From: Sacha Michel Mallais <email@hidden>)
 >Re: Best Design Practice (From: Owen McKerrow <email@hidden>)

  • Prev by Date: Re: Best Design Practice
  • Next by Date: Re: Best Design Practice
  • Previous by thread: Re: Best Design Practice
  • Next by thread: Re: Best Design Practice
  • Index(es):
    • Date
    • Thread