|
|
|
|
| Index | Recent Threads | Unanswered Threads | Who's Online | User List | Help |
DataNucleus Forum
DataNucleus Support
JDO API
Thread: Fetch groups behavior
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 5
|
|
| Author |
|
lfs
Novice Joined: Jun 16, 2009 Post Count: 24 Status: Offline |
Hi I'm getting started on DN and was reading about fetch groups and testing it, but I'm not seeing the behavior I'd expect normally. I'm using a simple city-state-country hierarchy as my testing objects, and using debugger to inspect query results. First of all, a clarification: reading the docs it seemed to imply that the only difference between make an object transient/retain values and detach is that only detached objects can be retached. What I saw was that detached objects get all fields reachable through fetch depth and the fetch group populated, while transient ones get only all the fields of the queried class plus the first depth objects with their id only. For my city objects, this means only getting the state object with its id, nothing else (not even String values), and not deeper than that (it won't fecth the country object for states). I expected transient objects to fetch all the fields just like detached ones, but this way transient are no more than shallow copies (is that why they can't be retached?) Second, when fetching this entire hierarchy of objects, I noticed that even with setDetachAllOnCommit(true), a city query at first did not retrieved all the objects up to country, and indeed the commit was needed for them to be available (object inspection on eclipse debug). Was it really performed by two queries (one at find() and other at commit() )? Wouldn't it be more efficient to fetch all the fields at once, when calling find()? Can I request that programatically? That's what I had in mind for now. Anyway, thanks to the staff for the awesome tool! You guys are saving me tons of painful SQL writing! |
||
|
|
wegorkie
Advanced Member Poland Joined: Jan 16, 2005 Post Count: 118 Status: Offline |
Second, when fetching this entire hierarchy of objects, I noticed that even with setDetachAllOnCommit(true), a city query at first did not retrieved all the objects up to country, and indeed the commit was needed for them to be available (object inspection on eclipse debug). Was it really performed by two queries (one at find() and other at commit() )? Generally the purpose of using JDO is to be kept out of such worries. IDE debugger may not be the best tool for analyzing lazy loading. Set log4j.category.DataNucleus.Datastore.Retrieve=DEBUG and you will see when the queries go. |
||
|
|
lfs
Novice Joined: Jun 16, 2009 Post Count: 24 Status: Offline |
Generally the purpose of using JDO is to be kept out of such worries. I wouldn't go so far to check the actual query... that's why I'm using JDO in the first place. I just noticed it because I was trying to understand the fetch groups and transient objects.  IDE debugger may not be the best tool for analyzing lazy loading. Set log4j.category.DataNucleus.Datastore.Retrieve=DEBUG and you will see when the queries go. Thanks! |
||
|
|
cyril
Member USA Joined: Nov 13, 2007 Post Count: 96 Status: Offline |
I understand that the only difference with detach is that it stores state/version data in a hidden jdoDetachedState field of the class so it can be re-attached + you can get callbacks by implementing DetachCallback interface. You can call makeTransient(jdo, true) so that it uses the fetch plan like detachCopy. You should only need to detach/makeTransient JDOs if you need to send them to another tier or outside the JVM. Most ORM take a lazy approach to dependency fetching and will fetch only what they need until you detach. Some dependencies are better loaded on first query with joins, others may not as they require separate queries anyway. DN does not have too many controls to customize how dependencies are fetched, but it does a fairly good job overall. You can encourage it to join aggressively by mapping 1o1 relationships with default-fetch-group=true or declare your custom fetch plan before the first query. ---------------------------------------- Cyril http://www.travelmuse.com |
||
|
|
lfs
Novice Joined: Jun 16, 2009 Post Count: 24 Status: Offline |
You can call makeTransient(jdo, true) so that it uses the fetch plan like detachCopy. Thanks, that is what I was looking for (shame on me... I should have checked the docs) You should only need to detach/makeTransient JDOs if you need to send them to another tier or outside the JVM. Most ORM take a lazy approach to dependency fetching and will fetch only what they need until you detach. Some dependencies are better loaded on first query with joins, others may not as they require separate queries anyway. DN does not have too many controls to customize how dependencies are fetched, but it does a fairly good job overall. You can encourage it to join aggressively by mapping 1o1 relationships with default-fetch-group=true or declare your custom fetch plan before the first query. For find*/get* style methods, detach/transient are handy, and I prefer to take a cautious road and use transient instead of detach. I used fetch groups before the first query, but they did not seem to perform eager fetch (seeing the actual query may prove I'm wrong). As some of my queries are plain simple and all queried objects will be detached (all cities in some state), force some eager/greedy fetching would be nice if possible. But... who cares? I'm not writing SQL! That's great already!  |
||
|
|
|
|
Current timezone is GMT Mar 18, 2010 11:00:44 AM |
