OTM M-N Mapping Issue
Hello there, I am using OTM with M-N mapping. I am having an issue with OTM, where OJB violate foreign key constraints. I have the following mapping: PREFS_NODE -- PREFS_NODE_PROPERTY_KEY -- PREFS_PROPERTY_KEY With OTM, OJB tries to delete PREFS_PROPERTY_KEY before removing PREFS_NODE_PROPERTY_KEY therefore violating foreign key constraint. Has anybody else experienced the same behavior. Regards, David Le Strat. __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extent
Hi, I am using PB-API and DB2 7 for a few weeks now and have a question regarding the ojb extent concept. I have a BaseClass which holds common attributes (timestamp, versionnr) for model objects. Each model class has to extent BaseClass. Database tables hold the common attributes and specific attributes for the appropriate model class. In the repository-user.xml I declared the common attributes separately for each model class-descriptor. My question is: Did I miss the ojb-extent concept totally? Could I just declare a model class as an extent-class of BaseClass and delete the common attributes from each (model)class-descriptor because of the extent, ojb would handle these attributes automatically for each extended class? thx, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Non decomposed problem
Hi all Some news on my problem ... In fact this behavior ( deletion of roles when removing the cross reference ) only occurs when I'm NOT using the ObjectCacheDefaultImpl caching strategie. It's strange to me ? Le sam 28/02/2004 à 02:32, olivier.nouguier a écrit : Hi all, I'm really lost with auto-delete feature... The model: 0,n 0,n Actors Roles The RDBMS schema: actors ( id, ... ) roles ( id, ... ) actors_roles ( actor_id, role_id ) The problem: With the attached repository.xml, when I remove a role from an actor, the role is also deleted from the table. But when I remove the actor, the role is kept ? All attribute are ( auto-update, auto-delete ) set to false. ojb-RC5 // Transaction tx = odmg.newTransaction(); tx.begin(); Actor actor = retrieveActor(id); tx.lock(actor, Transaction.WRITE); actor.removeRole(0); ( delegate actor.roles.remove(0) on a vector ) tx.commit(); // __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proxy objects for nonexisting references
Hi all, I've just changed my application to using dynamic proxies and I noticed some unexpected behaviour: even if a foreign key attribute is 0, OJB instantiates a proxy object (with 0 as primary key value). So all the existing tests that expect a null value if this reference does not exist now fail. To do the same test I now have to check the foreign key field for 0, but that field should better not appear in the interface. Is this by design or is there a way to change this? Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OTM M-N Mapping Issue
Hi David, If you use otm-dependent relations, then check the current CVS HEAD - I've just committed the fix. If not, then give more detailed description of your case. Regards, Oleg On Sunday 29 February 2004 08:09, David Le Strat wrote: Hello there, I am using OTM with M-N mapping. I am having an issue with OTM, where OJB violate foreign key constraints. I have the following mapping: PREFS_NODE -- PREFS_NODE_PROPERTY_KEY -- PREFS_PROPERTY_KEY With OTM, OJB tries to delete PREFS_PROPERTY_KEY before removing PREFS_NODE_PROPERTY_KEY therefore violating foreign key constraint. Has anybody else experienced the same behavior. Regards, David Le Strat. __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OTM M-N Mapping Issue
Thanks Oleg, just saw your commit ;). I use OTM. I will try the latest head. Regards, David. --- Oleg Nitz [EMAIL PROTECTED] wrote: Hi David, If you use otm-dependent relations, then check the current CVS HEAD - I've just committed the fix. If not, then give more detailed description of your case. Regards, Oleg On Sunday 29 February 2004 08:09, David Le Strat wrote: Hello there, I am using OTM with M-N mapping. I am having an issue with OTM, where OJB violate foreign key constraints. I have the following mapping: PREFS_NODE -- PREFS_NODE_PROPERTY_KEY -- PREFS_PROPERTY_KEY With OTM, OJB tries to delete PREFS_PROPERTY_KEY before removing PREFS_NODE_PROPERTY_KEY therefore violating foreign key constraint. Has anybody else experienced the same behavior. Regards, David Le Strat. __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent
Hi Dirk, I'm not sure whether I understood your problem. Maybe I can help anyway... First, I'm not sure whether you really need to declare the extents for all your classes. Wouldn't it be sufficient to simply have all model classes having the same superclass BaseClass. If this is the case, simply model write a class-descriptor for each model class without any extent declarations. The BaseClass doesn't even need an entry in the repository file. Of course, if you need to do queries using the BaseClass, this approach won't work. You would then need to declare the BaseClass in the repository with all it's extents. This would probably look like class-descriptor class=foo.bar.BaseClass extent-class class-ref=foo.bar.ModelClass1/ extent-class class-ref=foo.bar.ModelClass2/ ... extent-class class-ref=foo.bar.ModelClassN/ field-descriptor autoincrement=true primarykey=true column=id jdbc-type=VARCHAR name=id/ field-descriptor column=version jdbc-type=VARCHAR name=version/ /class-descriptor In the latter case, I think you would have to redeclare the id and version fields in each extent class together with the specific attributes for each extent class: class-descriptor class=foo.bar.ModelClass1 field-descriptor autoincrement=true primarykey=true column=id jdbc-type=VARCHAR name=id/ field-descriptor column=version jdbc-type=VARCHAR name=version/ field-descriptor column=fieldAFromClass1 jdbc-type=VARCHAR name=fieldAFromClass1/ field-descriptor column=fieldBFromClass1 jdbc-type=VARCHAR name=fieldBFromClass1/ /class-descriptor I'm not quite sure, whether it is really necessary to redeclare the common fields in each extent class, but I'm sure that it works this way as we are using this approach. The column names for the extent classes do not need to be the same for the same fields in different extent classes. Using the extent-approach, you will have one separate table for each model class, containing all the needed columns, included the inherited ones. Hope that helps, Peter Hi, I am using PB-API and DB2 7 for a few weeks now and have a question regarding the ojb extent concept. I have a BaseClass which holds common attributes (timestamp, versionnr) for model objects. Each model class has to extent BaseClass. Database tables hold the common attributes and specific attributes for the appropriate model class. In the repository-user.xml I declared the common attributes separately for each model class-descriptor. My question is: Did I miss the ojb-extent concept totally? Could I just declare a model class as an extent-class of BaseClass and delete the common attributes from each (model)class-descriptor because of the extent, ojb would handle these attributes automatically for each extended class? thx, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Extent
Hi Peter, my first repository-user.xml does not contain the extent concept at all. I simply did not set up a class-descriptor for BaseClass - just as you described. The extent concept came up to my mind when I thought that XDoclet would be a great time saver to set up the repository. For each attribute in the model class you declare an ojb.field, ojb.reference etc. Since the common attributes are in BaseClass I wondered how to set them up via XDoclet for each model class. That is why I guess U have to use the extent concept of ojb. Any idea? Dirk -Ursprüngliche Nachricht- Von: Peter Wieland [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 29. Februar 2004 16:47 An: [EMAIL PROTECTED] Betreff: Re: Extent Hi Dirk, I'm not sure whether I understood your problem. Maybe I can help anyway... First, I'm not sure whether you really need to declare the extents for all your classes. Wouldn't it be sufficient to simply have all model classes having the same superclass BaseClass. If this is the case, simply model write a class-descriptor for each model class without any extent declarations. The BaseClass doesn't even need an entry in the repository file. Of course, if you need to do queries using the BaseClass, this approach won't work. You would then need to declare the BaseClass in the repository with all it's extents. This would probably look like class-descriptor class=foo.bar.BaseClass extent-class class-ref=foo.bar.ModelClass1/ extent-class class-ref=foo.bar.ModelClass2/ ... extent-class class-ref=foo.bar.ModelClassN/ field-descriptor autoincrement=true primarykey=true column=id jdbc-type=VARCHAR name=id/ field-descriptor column=version jdbc-type=VARCHAR name=version/ /class-descriptor In the latter case, I think you would have to redeclare the id and version fields in each extent class together with the specific attributes for each extent class: class-descriptor class=foo.bar.ModelClass1 field-descriptor autoincrement=true primarykey=true column=id jdbc-type=VARCHAR name=id/ field-descriptor column=version jdbc-type=VARCHAR name=version/ field-descriptor column=fieldAFromClass1 jdbc-type=VARCHAR name=fieldAFromClass1/ field-descriptor column=fieldBFromClass1 jdbc-type=VARCHAR name=fieldBFromClass1/ /class-descriptor I'm not quite sure, whether it is really necessary to redeclare the common fields in each extent class, but I'm sure that it works this way as we are using this approach. The column names for the extent classes do not need to be the same for the same fields in different extent classes. Using the extent-approach, you will have one separate table for each model class, containing all the needed columns, included the inherited ones. Hope that helps, Peter Hi, I am using PB-API and DB2 7 for a few weeks now and have a question regarding the ojb extent concept. I have a BaseClass which holds common attributes (timestamp, versionnr) for model objects. Each model class has to extent BaseClass. Database tables hold the common attributes and specific attributes for the appropriate model class. In the repository-user.xml I declared the common attributes separately for each model class-descriptor. My question is: Did I miss the ojb-extent concept totally? Could I just declare a model class as an extent-class of BaseClass and delete the common attributes from each (model)class-descriptor because of the extent, ojb would handle these attributes automatically for each extended class? thx, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: success deploying ojb in jboss
Hi Michael and Andrew, I will integrate this approach (howto build an .ear file) in small section of the deployment doc. Any suggestions? regards, Armin Clute, Andrew wrote: Congrats on getting it to work! Sorry, I forgot to mention the need for your lib's to be in the CLASSPATH in the Manifest file. Isn't it nice to be able to redeploy also! -Andrew -Original Message- From: Michael Mogley [mailto:[EMAIL PROTECTED] Sent: Sat 2/28/2004 10:34 PM To: OJB Users List Subject: success deploying ojb in jboss Thanks Andrew and Armin. I followed Andrew's advice and packaged everything in one ear. Good news is I am also able to redeploy without having to restart the app-server (no OJB redeployment issues so far). Here's how I did it: /ejb.jar/ ...EJBs ...DAOs ...META-INF/ ..ejb-jar.xml ..jboss.xml ..MANIFEST.MF [Class-Path: /lib/ojb.jarCRLF] --- VERY IMPORTANT /lib/ ...ojb.jar /web-app.war/ ...JSP ...WEB-INF/ ..web.xml [ejb-refs to EJBs] /META-INF/ ...application.xml /OJB.properties /repository.xml /repository_database.xml /repository_user.xml It would have been great to have a template like this before I started. Hope this makes someone's life easier. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Extent
Hi Dirk, sorry, no idea how to use this with XDoclet. I pass on the question to the community. We use AXgen to generate everything based on an UML metamodel... Peter Hi Peter, my first repository-user.xml does not contain the extent concept at all. I simply did not set up a class-descriptor for BaseClass - just as you described. The extent concept came up to my mind when I thought that XDoclet would be a great time saver to set up the repository. For each attribute in the model class you declare an ojb.field, ojb.reference etc. Since the common attributes are in BaseClass I wondered how to set them up via XDoclet for each model class. That is why I guess U have to use the extent concept of ojb. Any idea? Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Armin Waibel wrote: Hi Robert, Robert S. Sfeir wrote: I have auto-retreive set to false in all my descriptors currently. Reason I do that is because sometimes I am not interested in getting the related objects, I just want to do a select from the table and just get the data back. However, there are times when I do want to fetch the related objects. So with that, I tried the following code below, but it seems that it's incorrect since my bean still returns a null for the related bean. final Query query = QueryFactory.newQuery( Category.class, crit ); broker.beginTransaction(); final ObjectReferenceDescriptor ord = new ObjectReferenceDescriptor( broker.getClassDescriptor( Project.class ) ); ord.setCascadeRetrieve( true ); OJB couldn't watch your made changes, 'ord' instance was not integrated. Why you don't use PB.retrieveAllReferences PB.retrieveReference for these objects you want to know the reference objects? That's the first thing I tried, but it returns null for my objects, I must not be using the code Right! Project p = new ProjectBean(); //TODO: Replace with Factory call. broker.retrieveAllReferences( p ); final List results = ( List ) broker.getCollectionByQuery( query ); Any help is appreciated. R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Hi, Robert S. Sfeir wrote: ... That's the first thing I tried, but it returns null for my objects, I must not be using the code Right! Project p = new ProjectBean(); //TODO: Replace with Factory call. broker.retrieveAllReferences( p ); final List results = ( List ) broker.getCollectionByQuery( query ); I don't know your ProjectBean class, but when you create a new object you can't find any reference object - or I'm wrong? regards, Armin Any help is appreciated. R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
That's the first thing I tried, but it returns null for my objects, I must not be using the code Right! Project p = new ProjectBean(); //TODO: Replace with Factory call. broker.retrieveAllReferences( p ); final List results = ( List ) broker.getCollectionByQuery( query ); I don't know your ProjectBean class, but when you create a new object you can't find any reference object - or I'm wrong? ah, I think you do the wrong turn and I misunderstood your example. Do after retrieve of the Category objects a final List results = ( List ) broker.getCollectionByQuery( query ); aCategoryObject = ...get from list broker.retrieveAllReferences( aCategoryObject ); call to get all reference objects for all Category instances you want to assign with the appropriate references. Armin regards, Armin Any help is appreciated. R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Armin Waibel wrote: Hi, Robert S. Sfeir wrote: ... That's the first thing I tried, but it returns null for my objects, I must not be using the code Right! Project p = new ProjectBean(); //TODO: Replace with Factory call. broker.retrieveAllReferences( p ); final List results = ( List ) broker.getCollectionByQuery( query ); I don't know your ProjectBean class, but when you create a new object you can't find any reference object - or I'm wrong? I should explain. I am doing a select on Category. a Category bean contains a get and set for a ProjectBean. a Category only relates to one Project. If I do the autoretrieve false then the projectBean object in the Category bean is null. If I set it to true, then it correctly contains a ProjectBean which the category relates to. Now sometimes I just want to get a list of categories, and I could care less that I get the ProjectBean with it, that's too heavy if I want to just display the category id and category name. Other times I need to do the whole thing, like for a category detail view. In that case I want to get all the ProjectBeans along with the category. Does this makes sense? So if I understood retrieveAllReferences, it will return all references of the object (ProjectBean) which relate to the category based on the fact that the Query object is querying Category.class. R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Armin Waibel wrote: That's the first thing I tried, but it returns null for my objects, I must not be using the code Right! Project p = new ProjectBean(); //TODO: Replace with Factory call. broker.retrieveAllReferences( p ); final List results = ( List ) broker.getCollectionByQuery( query ); I don't know your ProjectBean class, but when you create a new object you can't find any reference object - or I'm wrong? ah, I think you do the wrong turn and I misunderstood your example. Do after retrieve of the Category objects a final List results = ( List ) broker.getCollectionByQuery( query ); aCategoryObject = ...get from list broker.retrieveAllReferences( aCategoryObject ); call to get all reference objects for all Category instances you want to assign with the appropriate references. I think I know what you mean, but I'm confused about: aCategoryObject = ...get from list aCategoryObject do you mean my CategoryBean? what do you mean ...get from list? Are you saying that as I do my for loop to build my view objects, I should grab each CategoryBean, and then get the references to it then? Thanks R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Hi, Robert S. Sfeir wrote: I am doing a select on Category. a Category bean contains a get and set for a ProjectBean. a Category only relates to one Project. If I do the autoretrieve false then the projectBean object in the Category bean is null. If I set it to true, then it correctly contains a ProjectBean which the category relates to. Now sometimes I just want to get a list of categories, and I could care less that I get the ProjectBean with it, that's too heavy if I want to just display the category id and category name. Other times I need to do the whole thing, like for a category detail view. In that case I want to get all the ProjectBeans along with the category. Does this makes sense? yes of course! So if I understood retrieveAllReferences, it will return all references of the object (ProjectBean) which relate to the category based on the fact that the Query object is querying Category.class. seems my previous mail is lost in space ;-) Think you do the wrong order of commands. First retrieve the Category objects with a query. Then for all Category objects you want to assign references, call PB.retrieveAllReferences/retrieveReference. Or do I misunderstand your post (sorry my bad english)? regards, Armin R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Are you saying that as I do my for loop to build my view objects, I should grab each CategoryBean, and then get the references to it then? yes, that's how it is work currently. Maybe we should allow to override the auto-XXX settings on the fly by add setAutoXXX methods to query object or something similar in 1.1. Would be a nice feature and would allow what you expected. regards, Armin Robert S. Sfeir wrote: Armin Waibel wrote: That's the first thing I tried, but it returns null for my objects, I must not be using the code Right! Project p = new ProjectBean(); //TODO: Replace with Factory call. broker.retrieveAllReferences( p ); final List results = ( List ) broker.getCollectionByQuery( query ); I don't know your ProjectBean class, but when you create a new object you can't find any reference object - or I'm wrong? ah, I think you do the wrong turn and I misunderstood your example. Do after retrieve of the Category objects a final List results = ( List ) broker.getCollectionByQuery( query ); aCategoryObject = ...get from list broker.retrieveAllReferences( aCategoryObject ); call to get all reference objects for all Category instances you want to assign with the appropriate references. I think I know what you mean, but I'm confused about: aCategoryObject = ...get from list aCategoryObject do you mean my CategoryBean? what do you mean ...get from list? Are you saying that as I do my for loop to build my view objects, I should grab each CategoryBean, and then get the references to it then? Thanks R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing AutoRetrieve on the fly
Armin Waibel wrote: Are you saying that as I do my for loop to build my view objects, I should grab each CategoryBean, and then get the references to it then? yes, that's how it is work currently. Maybe we should allow to override the auto-XXX settings on the fly by add setAutoXXX methods to query object or something similar in 1.1. Would be a nice feature and would allow what you expected. Yup. That would be real nice to have it turned on and off. Think of it like AutoCommit. Sometimes you want to set that to true, and sometimes not. Ok let me ask a question another way, and perhaps the answer is the same... What if I turn auto-retrieve to true by default and then turn on some setting so that it does do the retreiveAllReferences(), is this the same problem? Thanks R - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: success deploying ojb in jboss
Hi Armin, I would have a brief summary of the approach and then just a diagram showing how all the pieces fit together. I would list it as a portable alternative to the sar version. Michael - Original Message - From: Armin Waibel [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Sunday, February 29, 2004 8:37 AM Subject: Re: success deploying ojb in jboss Hi Michael and Andrew, I will integrate this approach (howto build an .ear file) in small section of the deployment doc. Any suggestions? regards, Armin Clute, Andrew wrote: Congrats on getting it to work! Sorry, I forgot to mention the need for your lib's to be in the CLASSPATH in the Manifest file. Isn't it nice to be able to redeploy also! -Andrew -Original Message- From: Michael Mogley [mailto:[EMAIL PROTECTED] Sent: Sat 2/28/2004 10:34 PM To: OJB Users List Subject: success deploying ojb in jboss Thanks Andrew and Armin. I followed Andrew's advice and packaged everything in one ear. Good news is I am also able to redeploy without having to restart the app-server (no OJB redeployment issues so far). Here's how I did it: /ejb.jar/ ...EJBs ...DAOs ...META-INF/ ..ejb-jar.xml ..jboss.xml ..MANIFEST.MF [Class-Path: /lib/ojb.jarCRLF] --- VERY IMPORTANT /lib/ ...ojb.jar /web-app.war/ ...JSP ...WEB-INF/ ..web.xml [ejb-refs to EJBs] /META-INF/ ...application.xml /OJB.properties /repository.xml /repository_database.xml /repository_user.xml It would have been great to have a template like this before I started. Hope this makes someone's life easier. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Non decomposed problem
Hi all, In fact I think I found that when cache is NOT the default, the collection used are the RemovalAwareCollection then the BUG is on the afterStore callback. Am I right? Is there another solution?Why did such collection are used in this case? Thank Have a nice end week end Le dim 29/02/2004 à 15:23, olivier.nouguier a écrit : Hi all Some news on my problem ... In fact this behavior ( deletion of roles when removing the cross reference ) only occurs when I'm NOT using the ObjectCacheDefaultImpl caching strategie. It's strange to me ? Le sam 28/02/2004 à 02:32, olivier.nouguier a écrit : Hi all, I'm really lost with auto-delete feature... The model: 0,n 0,n Actors Roles The RDBMS schema: actors ( id, ... ) roles ( id, ... ) actors_roles ( actor_id, role_id ) The problem: With the attached repository.xml, when I remove a role from an actor, the role is also deleted from the table. But when I remove the actor, the role is kept ? All attribute are ( auto-update, auto-delete ) set to false. ojb-RC5 // Transaction tx = odmg.newTransaction(); tx.begin(); Actor actor = retrieveActor(id); tx.lock(actor, Transaction.WRITE); actor.removeRole(0); ( delegate actor.roles.remove(0) on a vector ) tx.commit(); // __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using single persistence broker instance
Michael Mogley wrote: EJB. I currently create a single instance during ejbCreate and keep it for the duration of the bean's lifecycle. This seems like the most efficient way. Is there a danger to using this approach when transactions and distributed caches are involved? Any other potential pitfalls? There could be a problem with the used connections when read-only operations (without tx-demarction) were performed. PB instance obtain a connection when needed. On PB.commitTransaction/abortTransaction (internal called in managed environments) and PB.close the connection was released. Are you saying the connection must be released for read-only operations? I am not understanding. Is there some danger to keeping a connection constantly open (so long as serial access is ensured)? The connection/DataSource handle could get timed out and PB show unexpected behaviour. Could be a performance issue, hundered open connections (each bean has a bean pool and each bean may have an open connection). Your appServer connection pool could exhaust. regards, Armin Michael On read-only operations (no cm-tx or bm-tx used/required) only on PB.close the connection was released. In your case the association between PB instance and connection may not be detached. You can do this manually by calling PB.serviceConnectionManager().releaseConnection() for read-only methods, but I don't recommend this when using cm-tx, because tx declaration in DD may change and I'm not sure if this could cause side-effects. regards, Armin Just want to make sure I'm not asking for trouble down the road. Thanks, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OTM] collection-descriptor issue with latest from head.
On Sunday 29 February 2004 19:24, David Le Strat wrote: When I update the NodeImpl with new nodeProperties (a collection), only the NodeImpl object gets updated and the nodeProperies are not created. I have done this in the past with PB with out any issues. Any suggestions? With auto-update=true nodeProperties should be creates, whatever you use, PB or OTM. I've just done correspondent test with OTM, and all is okay. So please send me code snippet or just try to do the same with PB. OTM does nothing special when auto-update=true, it just calls broker.store(). If you set auto-update=false and otm-dependent=true, then OTM itself will take care about creation and deletion of nodeProperties. Regards, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
