TranQL/OpenEJB enforce-foreign-key-constraints

[Aaron Mulder <am...@alumni.princeton.edu>]

	So in your CMP settings, you can include the
enforce-foreign-key-constraints setting.  This ultimately causes TranQL to
use either a SimpleFlushStrategy or an EnforceRelationshipsFlushStrategy.  
I just want to double-check my understanding of this.

	Is it the case that this controls what happens when you have
pending DB changes at the end of a transaction, and TranQL has to decide
what SQL to execute?  So with the SimpleFS, it just does the
inserts/updates/deletes in whatever order it feels like.  With the
EnforceRelationshipsFS, it tries to order them according to relationships
between tables -- for example, when deleting a parent with children, it
would issue the child deletes first.

	I assume this needs to be set if your DB enforces foreign keys as 
each statement is executed, and does not need to be set if your DB doesn't 
enforce foreign keys until the transaction is committed.

	If all that's right, then my last question is, are the
calculations for the EnforceRelationshipsFS based on inspecting the DB
schema via DBMetaData or something, or are they strictly based on Entity
relationships you may have declared in your ejb-jar.xml?

Thanks,
	Aaron

Re: TranQL/OpenEJB enforce-foreign-key-constraints

[Dain Sundstrom <da...@iq80.com>]

On Jun 12, 2005, at 7:18 PM, Aaron Mulder wrote:

>     So in your CMP settings, you can include the
> enforce-foreign-key-constraints setting.  This ultimately causes  
> TranQL to
> use either a SimpleFlushStrategy or an  
> EnforceRelationshipsFlushStrategy.
> I just want to double-check my understanding of this.
>
>     Is it the case that this controls what happens when you have
> pending DB changes at the end of a transaction, and TranQL has to  
> decide
> what SQL to execute?  So with the SimpleFS, it just does the
> inserts/updates/deletes in whatever order it feels like.  With the
> EnforceRelationshipsFS, it tries to order them according to  
> relationships
> between tables -- for example, when deleting a parent with  
> children, it
> would issue the child deletes first.
>
>     I assume this needs to be set if your DB enforces foreign keys as
> each statement is executed, and does not need to be set if your DB  
> doesn't
> enforce foreign keys until the transaction is committed.

Aaron,

This is my understanding, but hopefully Gianny will respond with a  
definitive answer.

>     If all that's right, then my last question is, are the
> calculations for the EnforceRelationshipsFS based on inspecting the DB
> schema via DBMetaData or something, or are they strictly based on  
> Entity
> relationships you may have declared in your ejb-jar.xml?

I don't think TranQL uses DBMetaData at all.

-dain

Re: TranQL/OpenEJB enforce-foreign-key-constraints

[Jeremy Boynes <jb...@apache.org>]

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

Re: TranQL/OpenEJB enforce-foreign-key-constraints

[Aaron Mulder <am...@alumni.princeton.edu>]

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.  :)

Thanks,
	Aaron

Re: TranQL/OpenEJB enforce-foreign-key-constraints

[Jeremy Boynes <jb...@apache.org>]

Aaron Mulder wrote:
> 	So in your CMP settings, you can include the
> enforce-foreign-key-constraints setting.  This ultimately causes TranQL to
> use either a SimpleFlushStrategy or an EnforceRelationshipsFlushStrategy.  
> I just want to double-check my understanding of this.
> 
> 	Is it the case that this controls what happens when you have
> pending DB changes at the end of a transaction, and TranQL has to decide
> what SQL to execute?  So with the SimpleFS, it just does the
> inserts/updates/deletes in whatever order it feels like.  With the
> EnforceRelationshipsFS, it tries to order them according to relationships
> between tables -- for example, when deleting a parent with children, it
> would issue the child deletes first.
> 
> 	I assume this needs to be set if your DB enforces foreign keys as 
> each statement is executed, and does not need to be set if your DB doesn't 
> enforce foreign keys until the transaction is committed.
> 

Yes, the simple strategy is just that and pays no attention to ordering 
requirements imposed by the model. The most likely use case is for when 
you have no DB level constraints in place (or they are disabled) as most 
RDBMS systems are not real happy if you defer enforcement to commit time.

> 	If all that's right, then my last question is, are the
> calculations for the EnforceRelationshipsFS based on inspecting the DB
> schema via DBMetaData or something, or are they strictly based on Entity
> relationships you may have declared in your ejb-jar.xml?
> 

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.

--
Jeremy