Aaron Mulder wrote:
On Sun, 12 Jun 2005, Jeremy Boynes wrote:
They are based on the info in the logical data model which for now is
defined by the relationships in the EJB model and not by the database.
The architecture allows for the separation of the three models
(front-end (EJB), logical and back-end (DBMS)) so at some point in the
future expect this to also include information from all of those models
not just the front-end one.
Thanks. Which leads me to another question:
When you execute a finder, does Geronimo load all beans related to
the target(s) or no related beans (until appropriate CMR getters are
invoked)? It seems like there are going to be performance issues either
way, just different ones. I'm hoping for "no related beans", because
otherwise you have the potential for big graph loads which I think is the
more painful problem of the two.
I also understand that Gianny is working on some kind of CMP/CMR
load groups, which will solve this -- I guess it can go on the road map
for now. :)
Yes, for now when you execute a finder the default is just to pull back
the PK fields of the rows that match. You can, IIRC, override the EJB-QL
manually and add in additional fields for a manual prefetch of
additional CMP fields or related data.
I believe Gianny is working on extending this to allow a query to be
specified on CMR navigation, allowing additional data to be fetched for
any related entities (to an arbitrary depth).
The general principle in play is that there are trigger events where we
miss the cache and go to the underlying database. When that happens, the
query can pull back anything and the entire result is added into the
cache. We generate default queries but for performance we would expect
users to define pre-fetch queries that match the access pattern their
code is using.
--
Jeremy
