Re: mapping the same class to multiple tables?
I have a similar solution in my job. I've done in the following way:
class A {
...
}
class A_normal extends A {
}
class A_history extends A {
}
Only A_normal and A_history are mapped in repository.xml.
So, if I need to manipulate the object, I use class A. To store a normal object, I use
and
instance of A_normal. If I need to store a history object, I use A_history. Now, if I
need
to move one object A_normal to A_history, I use the method copyProperties in
common-beans
library to do the job. The I start a transaction, delete A_normal and insert the
A_history.
I think can be several ways to get job done, this is just one.
Best regards,
Richter
My application has to support undo using persistence, as someone must be able to
change a
previously entered field after closing and re-opening the application.
All of my classes extend my own PersistentObject class, but certain classes can be
entered
into the History (to be undone later), and those classes implement a marker
interface
called Enterable.
I'd like to have two methods as follows:
store(PersistentObject)
storeEnterable(Enterable)
where storeEnterable() would store the Enterable in a history table. Is this
possible?
--
Liam Morley
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: clear() collection proxy RemovalAware
Is this already in CVS? This fix is correct?
Thanks,
Edson Richter
After some research, I've found an implementation that works:
public void clear()
{
Collection coll;
if(getData()instanceof ManageableCollection) {
getData().clear(); // ECER: assure it will notify all being
removed, necessary for RemovalAware classes...
} else {
// BRJ: use an empty collection so isLoaded will return true
try
{
coll = (Collection) getCollectionClass().newInstance();
}
catch (Exception e)
{
coll = new ArrayList();
}
setData(coll);
_size = 0;
}
}
Could someone cofirm/fix this in CVS?
Thanks,
Edson Richter
Edson Carlos Ericksson Richter wrote:
I think I and a co-worker (Igor) found a little bug in collection
proxy. When using RemovalAware... as class for a collection
descriptor, calling clear() in the collection don't register the
objects for deletion. The answer is the clear implementation in
CollectionProxyDefaultImpl:
public void clear()
{
Collection coll;
// BRJ: use an empty collection so isLoaded will return true
try
{
coll = (Collection) getCollectionClass().newInstance();
}
catch (Exception e)
{
coll = new ArrayList();
}
setData(coll);
_size = 0;
}
I think the right method should be:
public void clear()
{
Collection coll;
getData().clear(); // ECER: assure it will notify all being
removed, necessary for RemovalAware classes...
// BRJ: use an empty collection so isLoaded will return true
try
{
coll = (Collection) getCollectionClass().newInstance();
}
catch (Exception e)
{
coll = new ArrayList();
}
setData(coll);
_size = 0;
}
Could you analize and report if this is right?
Thanks,
Edson Richter
-
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]
Latest CVS/CollectionProxy
Since yesterday (I've downloaded CVS HEAD sources and compiled), I can't get a collection-descriptor using class=org...RemovalAwareList work correctly with proxy=dynamic. The stack trace is: java.lang.ClassCastException at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(QueryReferenceBroker.java:862) at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.init(QueryReferenceBroker.java:784) at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.init(QueryReferenceBroker.java:855) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:537) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:683) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:471) at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:265) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:119) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:230) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:250) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1205) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:331) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:331) and so on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latest CVS/CollectionProxy
The problem was caused by a setXXX(List l) where the programmer is not storing a reference to the RemovalAwareList, but creating a new list with the contents. Then, when using getXXX(), the returned list isn't the RemovalAwareList but a java.util.ArrayList. I think this is not correct, but this is not occuring in older OJB releases... Best regards, Edson Richter Since yesterday (I've downloaded CVS HEAD sources and compiled), I can't get a collection-descriptor using class=org...RemovalAwareList work correctly with proxy=dynamic. The stack trace is: java.lang.ClassCastException at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(QueryReferenceBroker.java:862) at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.init(QueryReferenceBroker.java:784) at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.init(QueryReferenceBroker.java:855) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:537) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:683) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:471) at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:265) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:119) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:230) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:250) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1205) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:331) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:331) and so on. - 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: MtoNCollectionPrefetcher.buildPrefetchCriteriaMultipleKeys(MtoNCollect ionPrefetcher.java:338)
I think A way is more correct, besides more complex in some situations... hi edson, looks like my question wasn't clear enough ;) i know the join i have to do but i'm not sure about how to select the multiple keys when retrieving all A for several Cs: A) select * from A join B on A.A1 = B.A1 and A.A2 = B.A2 join C on C.C1 = B.C1 and C.C2 = B.C2 and C.C3 = B.C3 where (C.C1 = 1 and C2 = 2 and C.C3 = 3) or (C.C1 = 11 and C2 = 12 and C.C3 = 13) or (C.C1 = 21 and C2 = 22 and C.C3 = 23) or (C.C1 = 31 and C2 = 32 and C.C3 = 33) (C.C1 = and C2 = and C.C3 = ) will be repeated for every C. this will result in a quite complex sql depending on the number of Cs. an alternative would be to use IN-statement as in single-key : B) select * from A join B on A.A1 = B.A1 and A.A2 = B.A2 join C on C.C1 = B.C1 and C.C2 = B.C2 and C.C3 = B.C3 where C.C1 in ( 1, 11, 21, 31) and C.C2 in ( 2, 12, 22, 32) and C.C3 in ( 3, 13, 23, 33) the query is simpler but may return more As than necessary because the IN-statements do not constrain the combination of keys. i prefer alternative A) what do you think ? jakob Edson Carlos Ericksson Richter wrote: Thinking less abstract, the field names of PK in A object are same field names in B table, as the field names of PK in C are the same field names in B. So, if A has the fields A1, A2 (PKs), and C has fields C1, C2, C3 (PKs), then B has fields A1, A2, C1, C2, C3. So, the select will be: select * from A join B on A.A1 = B.A1 and A.A2 = B.A2 join C on C.C1 = B.C1 and C.C2 = B.C2 and C.C3 = B.C3 IMHO, the names of the fields are not important, but their position. The pointing-to-this-class should be understood as 1st PK is pointing to first field, and 2nd PK to the 2nd field. The first pointing-to-element should be mapped to 1st PK in the N element, the 2nd to the second PK, and the 3rd, to 3rd PK. As far as I can see, the MtoN must know the CDS of the M element and the N element, so the mapping could be done. Richter Edson Carlos Ericksson Richter wrote: The expected result is something like A-B-C Where A is M side has PK with 2 fields, C is N side has PK with 3 fields, B is indirection table, and has 5 fields. select * from A join B on A.field1 = B.field1 and A.field2 = B.field2 join C on C.field1 = B.field3 and C.field2 = B.field4 and C.field3 = B.field5 I expect this help. Edson Richter Jakob Braeuchi wrote: hi edson, imo the whole handling of the multi-key criteria is a little bit weird. what should the sql look like in your case ? jakob Edson Carlos Ericksson Richter wrote: Hum... There is some instability here. I don't know what combination of dynamic proxies/collection proxies is causing this bug. I've fixed using either proxy=true in the collections inside each bean... Why? I really don't know. I'll need to compare each of the 12 collections involved in this beans to know what's give the stack trace... I'll need sometime to restart the app 132 times to know :( Anyway, if someone could send me the rc5 implementation of the method, so I can compare with actual, I'll appreciate. Thanks in advantage. Edson Richter - Original Message - From: Edson Carlos Ericksson Richter To: 'OJB Users List' Sent: Wednesday, March 24, 2004 2:46 PM Subject: MtoNCollectionPrefetcher.buildPrefetchCriteriaMultipleKeys(MtoNCollectionPre fetcher.java:338) This bug is driving me crazy... Someone could point me what changed from rc5 to 1.0 in this method (so I can at least fix locally)? The problem is a M:N mapping using composite pk pointing the M bean, and 1 field pk pointing to the N bean. The stack trace is: java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.buildPrefetchCrit eriaMultipleKeys(MtoNCollectionPrefetcher.java:338) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.buildPrefetchCrit eria(MtoNCollectionPrefetcher.java:259) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.buildPrefetchQuer y(MtoNCollectionPrefetcher.java:115) at org.apache.ojb.broker.accesslayer.CollectionPrefetcher.buildPrefetchQueries( CollectionPrefetcher.java:93) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.prefetchRelations hip(MtoNCollectionPrefetcher.java:68) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryR eferenceBroker.java:277) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:146) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:203) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis tenceBrokerImpl.java:1046) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery
Re: MtoNCollectionPrefetcher.buildPrefetchCriteriaMultipleKeys(MtoNCollect ionPrefetcher.java:338)
I'll try that ASAP... Richter hi armin, edson, i commited a small fix to this problem. it still uses sql alternative A) the NPE is imo due to a type mismatch when building the Identities, see the comment in associateBatched. jakob Jakob Braeuchi wrote: hi edson, looks like my question wasn't clear enough ;) i know the join i have to do but i'm not sure about how to select the multiple keys when retrieving all A for several Cs: A) select * from A join B on A.A1 = B.A1 and A.A2 = B.A2 join C on C.C1 = B.C1 and C.C2 = B.C2 and C.C3 = B.C3 where (C.C1 = 1 and C2 = 2 and C.C3 = 3) or (C.C1 = 11 and C2 = 12 and C.C3 = 13) or (C.C1 = 21 and C2 = 22 and C.C3 = 23) or (C.C1 = 31 and C2 = 32 and C.C3 = 33) (C.C1 = and C2 = and C.C3 = ) will be repeated for every C. this will result in a quite complex sql depending on the number of Cs. an alternative would be to use IN-statement as in single-key : B) select * from A join B on A.A1 = B.A1 and A.A2 = B.A2 join C on C.C1 = B.C1 and C.C2 = B.C2 and C.C3 = B.C3 where C.C1 in ( 1, 11, 21, 31) and C.C2 in ( 2, 12, 22, 32) and C.C3 in ( 3, 13, 23, 33) the query is simpler but may return more As than necessary because the IN-statements do not constrain the combination of keys. i prefer alternative A) what do you think ? jakob Edson Carlos Ericksson Richter wrote: Thinking less abstract, the field names of PK in A object are same field names in B table, as the field names of PK in C are the same field names in B. So, if A has the fields A1, A2 (PKs), and C has fields C1, C2, C3 (PKs), then B has fields A1, A2, C1, C2, C3. So, the select will be: select * from A join B on A.A1 = B.A1 and A.A2 = B.A2 join C on C.C1 = B.C1 and C.C2 = B.C2 and C.C3 = B.C3 IMHO, the names of the fields are not important, but their position. The pointing-to-this-class should be understood as 1st PK is pointing to first field, and 2nd PK to the 2nd field. The first pointing-to-element should be mapped to 1st PK in the N element, the 2nd to the second PK, and the 3rd, to 3rd PK. As far as I can see, the MtoN must know the CDS of the M element and the N element, so the mapping could be done. Richter Edson Carlos Ericksson Richter wrote: The expected result is something like A-B-C Where A is M side has PK with 2 fields, C is N side has PK with 3 fields, B is indirection table, and has 5 fields. select * from A join B on A.field1 = B.field1 and A.field2 = B.field2 join C on C.field1 = B.field3 and C.field2 = B.field4 and C.field3 = B.field5 I expect this help. Edson Richter Jakob Braeuchi wrote: hi edson, imo the whole handling of the multi-key criteria is a little bit weird. what should the sql look like in your case ? jakob Edson Carlos Ericksson Richter wrote: Hum... There is some instability here. I don't know what combination of dynamic proxies/collection proxies is causing this bug. I've fixed using either proxy=true in the collections inside each bean... Why? I really don't know. I'll need to compare each of the 12 collections involved in this beans to know what's give the stack trace... I'll need sometime to restart the app 132 times to know :( Anyway, if someone could send me the rc5 implementation of the method, so I can compare with actual, I'll appreciate. Thanks in advantage. Edson Richter - Original Message - From: Edson Carlos Ericksson Richter To: 'OJB Users List' Sent: Wednesday, March 24, 2004 2:46 PM Subject: MtoNCollectionPrefetcher.buildPrefetchCriteriaMultipleKeys(MtoNCollectionPre fetcher.java:338) This bug is driving me crazy... Someone could point me what changed from rc5 to 1.0 in this method (so I can at least fix locally)? The problem is a M:N mapping using composite pk pointing the M bean, and 1 field pk pointing to the N bean. The stack trace is: java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.buildPrefetchCrit eriaMultipleKeys(MtoNCollectionPrefetcher.java:338) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.buildPrefetchCrit eria(MtoNCollectionPrefetcher.java:259) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.buildPrefetchQuer y(MtoNCollectionPrefetcher.java:115) at org.apache.ojb.broker.accesslayer.CollectionPrefetcher.buildPrefetchQueries( CollectionPrefetcher.java:93) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.prefetchRelations hip(MtoNCollectionPrefetcher.java:68) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryR eferenceBroker.java:277) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:146) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:203
Re: [ann] new release 1.0.RC6
Hmmm, what about the 1:0..1 and proxies test for null is always false and the
afterStore
not being called for collections? Are they fixed too?
Best regards,
Edson Richter
Dear all,
We've got a new release! Given we find no showstoppers during the next
week we will approach the Project Management Committee (PMC) of the
db.apache.org project to get approval to relabel this release as the
final 1.0 version.
Armin worked hard to get our regression testbed rocksolid. We now have
more than 600 testcases covering all major areas of the framework!
I'm confident that this testsuite will help us to maintain and even
increse the reliability of our code from release to release.
Thanks to all who helped and contributed to this release!
--Thomas
From the release notes:
-
Release 1.0 rc6
-
NEW FEATURES:
-
NOTES:
- Repository.dtd has changed, don't forget to replace this file
- Upgraded to the new Apache License, Version 2.0
- No support for HSQLDB 1.7.2RC1 yet
- No support for Torque 3.1 yet
- Add new PersistenceBrokerFactory implementation for use in managed
environments when *only* the
PB-api was used and participation in JTA transaction via Synchronization
interface is needed.
- Add new configuration property 'autoSync' to ObjectCacheDefaultImpl.
Used to enable a simple
synchronization mechanism to keep cache in sync with DB
- Add new attribute values for reference-/collection-descriptor
auto-update/-delete attribute.
Now we have five possible values: none, link, object, true, false. The
true, false values
are now deprecated but will NOT be removed in near future (so don't panic!).
CHANGES:
- fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was
INTEGER but
needs BIGINT to support Long on java side
- no longer throw an exception when calling abortTransaction more than
one time
or an internal rollback (by ConnectionManager on the used connection)
was already done
- Add object-cache tag in standard jdbc-connection-descriptor in
repository_database.xml
to enable new 'autoSync' property of ObjectCacheDefaultImpl for all
operations made by
this DB connection
- Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl
(handle with care ;-))
- odmg-api implementation, disable restore of transient objects on
transaction abort,
because we can't really restore the whole object with all references
- now using ANTLR 2.7.2 and Unicode support in OQL queries
- now using ANT 1.6.0
- RelationshipPrefetcher no longer modifies auto-retrieve setting of
Relationship-Descriptor.
This may result in additional sql-queries but is safer in a
multi-threaded environment.
- Added column methods to Criteria. addColumnEqualTo, addColumnIn etc.
The column parameter
of these methods will not be translated during sql-generation. These
methods are mainly used
for internal purpose.
BUG FIXES:
Please refer to our Bug tracking site
(http://issues.apache.org/scarab/servlet/scarab/)
under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx
to see details for a bug with id OJBxxx.
- fix bug in MetadataManager, when 'per thread changes' is enabled and
many different
DescriptorRepository instances were used, gc can't collect unused
instances because
StatementManager doesn't release references to used DescriptorRepository
instances.
- fix bug in ObjectCacheDefaultImpl, it doesn't make sense to use a soft
reference
for the object wrapper of the cached object. Use a softreference for the
cached
object instead
- fix bug in CacheDistributor (internal used ObjectCache
implementation), each CacheDistributor
instance have to held ObjectCache instances for the associated
PersistenceBroker instance
- fix documentation bug in ObjectCacheDefaultImpl, property 'timeout' use
seconds instead of milliseconds
- fix bug in new DList implementation (DListImpl_2), materialization of
objects
failed when DList instance itself was persisted (using db.bind(...)) and
re-loaded within tx, but iteration over the list values was done outside
of the tx
- The bogus ODMG Distributed Lockmanagement feature has been replaced by
a new
Servlet based LockServer. Transaction isolation should now work
properly even
accross a cluster of JVMs.
- fix bug in MtoNCollectionPrefetcher, multi-key handling is now supported.
- ClassCastException with ManageableCollection implementations on m:n
relation.
m:n relation now can handle ManageableCollection collection classes in a
correct way,
the collection class no longer needs to implement java.util.Collection.
KNOWN ISSUES:
- odmg-api: It is not possible to exchange objects in 1:n references.
E.g. two objects with 1:n reference, each with one reference object,
obj_1{ref_1}
and obj_2{ref_2}. Lock objects and exchange the references
Re: RE : Query Performance
To see what exactly being going to/from database server, enable P6Spy. I'm using p6spy with sqlprofiler tool, and I get exactly information passing between OJB and database server (not only sql commands, but including data sen't and returned). Edson Richter Hello, I think I need to give you more explanation. In our production environnement, a website page takes 6 minutes to be displayed. And I think it is not enough quick ;-) In order to find the performance problem, we added some logs and found that the following code was the problem (and takes 6 minutes) : list = broker.getCollectionByQuery(requete); broker.commitTransaction(); This query returns only 10 records (with simple data, no lob). I thought it was an Oracle performance problem so with the debug mode, I found the generated query. This query is not optimised, but when I tried it on the database, it only takes 4 secondes to be executed. I'm sure that the mapping is bad but i don't understand such difference between executing a query directly from a database and with OJB. So here are my questions : 1) Is the query displayed in the log server (with obj properties org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG ) really the query executed on the database by OJB? 2) How really works OJB to retrieve data from a database? Thanks a lot. Yannick -Message d'origine- De : Yannick Goujon [mailto:[EMAIL PROTECTED] Envoyé : mardi 16 mars 2004 14:56 À : [EMAIL PROTECTED] Objet : Query Performance Hi, We use Oracle 8.1.7 and we have performance problem with a query generated by OJB. With OJB, it takes 6 minutes (maybe due to a bad mapping). We found the generated query by changing the LogLevel of the sql generator (org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBU G) When we try this query directly under sqlplus, it only takes 4 secondes! Can someone explain me why is it so long with OJB? Is it due to a bad mapping or a bad configuration of OJB? Thanks Yannick - 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: Re: delete relation in indirection-table
As far as I remember, this behaviour was changed since 0.96 or 0.97 - I'm not sure. Of course, a DTD comment alerting that RemovalAwareCollection is default is very welcome. And changes in DOCs, specially relative to M:N mapping, recommending to not use default value for collection-class IMHO is mandatory. Edson Richter Hi all, Nope I didn't found any thing on the subject, I found this behaviour while debugging ojb ( thank to eclipse ). And then reading comment in example bundled with ojb. Same behaviour with all ( I played with ) layer ( odmg, PB ). It's should be documented AND specified that default collection class is RemovalAwareCollection ... Really happy to give ( this insignifiant ... ) help AND many many many thank for ojb, document in general is very well done. Message du 04/03/04 10:24 De : Armin Waibel [EMAIL PROTECTED] A : OJB Users List [EMAIL PROTECTED] Copie à : Objet : Re: delete relation in indirection-table Hi all, is this behaviour documented? regards, Armin Klaus Ripplinger wrote: Hi Olivier, Hi Edson, using MangeableVector solved the problem! thanks a lot! You're very welcome ! Klaus - 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
For M:N mappings, you should not use auto-delete (that will remove the M or N side - depending on config/code). You should use 'auto-delete=false' and a 'collection-class=org.apache.ojb.broker.util.RemovalAwareCollection' (I don't remember the complete class name - please, double check it). This make OJB remove only the middle object (not the real objects, only the mapping between them). BUT, after I write all this things (and re-checing your e-mail to see if I missed something), I remembered to alert you that my tip is based on PB Api (that I really use), not ODMG. Someone else more familiarized on ODMG could give you more orientation (or confirm is this solution works with ODMG too). Best regards, Edson Richter 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]
Delete object in 1-N relationship not setting referencing objects to null
Hi! I have a new situation in my project. I've an object that is referenced by other objects. The relationship is 1-N. When I delete the Object in 1 side, and the auto-delete if false, then I expect the N side object should be set to null in referencing field. This is not happening. Is this a expected behaviour, or is needed some kind of config I lost? In meantime, I've created a trigger in database to do this job, so it isn't a real problem, but I think it's should be managed by OJB. Thanks for any tips, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help, I'm stuck and I can't get out! (Infinite Loop)
It isn't a bug. Actually, it's a Feature by design. Since I don't maintain cache of objects (this is the behaviour of EmptyCache), there is no way to know that the object is loaded. So it will load. If the loaded object has references to the first object, it will load the first object again, and so on. In the circunstances where I can't avoid two way navigable references, I use object-cache tag per object. In all other places I work with EmptyCache and there is no problem. Thats my experience, and may not be true for rc5, since I working with some outdated HEAD rc4. Best regards, Edson Richter For the slow people in the class, can you please explain this problem in a little more detail? If I have to tweak cache timeouts to get correct behavior on simple references, then there 's a bug hiding in here somewhere. Thanks. Edson Carlos Ericksson Richter wrote: Exists some circustantes that results in infinite loop due to use of EmptyCache with two way navigable references. Are you using this? If yes, try to set a object-cache in the recerenced bean with a very low time-out (let's say, 1 sec). It solved almost vast majority of my cases. Best regards, Edson Richter - Original Message - From: Clay Mitchell To: OJB Users List Sent: Saturday, February 07, 2004 2:16 PM Subject: Help, I'm stuck and I can't get out! (Infinite Loop) I seem to have gotten myself stuck in a infinite loop here... Any idea what it's doing and why? Thanks -Clay [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.ProductType, Query from class com.exigentic.onyx.ProductType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Product, Query from class com.exigentic.onyx.Product where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.SpecType, Query from class com.exigentic.onyx.SpecType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [specId = 28]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false ## Here's my repository: ?xml version=1.0 encoding=UTF-8? !DOCTYPE descriptor-repository PUBLIC -//Apache Software Foundation//DTD OJB Repository//EN repository.dtd descriptor-repository version=1.0 isolation-level=read-uncommitted jdbc-connection-descriptor jcd-alias=default default-connection=true platform=PostgreSQL jdbc-level=3.0 driver=org.postgresql.Driver protocol=jdbc subprotocol=postgresql dbalias=//192.168.1.101:5432/onyx username=postgres password=t30a6az8z eager-release=false batch-mode=false useAutoCommit=1 ignoreAutoCommitExceptions=false connection-pool maxActive=21 validationQuery=/ sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl attribute attribute-name=autoNaming attribute-value=true/ /sequence-manager /jdbc-connection-descriptor class-descriptor class=com.exigentic.onyx.Account table=ACCOUNT field-descriptor name=id primarykey=true default-fetch=true autoincrement=true sequence-name=account_seq'::text column=ACCOUNT_ID jdbc-type=INTEGER/ field-descriptor name=email nullable=false default-fetch=true column=EMAIL jdbc-type=VARCHAR/ field-descriptor name=password nullable=false default-fetch=true column=PASSWORD jdbc-type=VARCHAR/ field-descriptor name=firstName nullable=false default-fetch=true column=NAME_FIRST jdbc-type=VARCHAR/ field-descriptor name=lastName nullable=false default-fetch=true column=NAME_LAST jdbc-type=VARCHAR/ field-descriptor name=company default-fetch=true column=COMPANY jdbc-type
Re: FW: NetBeans and OJB
Hi! Just more 2c: When running app in NetBeans using Internal Execution Mode, it always set working directory to %NETBEANS_HOME%\bin (hipotetical path - adapt to your OS of preference). I don't know if there is a way to change this programmatically, and you can have trouble with this kind of setting due to security of Java when deploying your app. The only way (using default NetBeans options, withou hacking anything) to specify a user working directory (where your .properties, .xml and so on are) is using the External Execution Mode. About the JARs (as Armin mentioned), I assume that you have mounted all OJB .jar files in your NetBeans file systems, right? That's all. It work like a charm... AFAIK, there is no separated classloader (just for laughs: some time ago, I have created an Swing component that when diabled, if take the container it was inside, and disable too, then, the container of the container and disable too, and so on. The first time I used the component in a form using the Visual From Editor, and set Enabled=false, I've disabled all NetBeans interface!!! Yes, the Visual Form Editor was running my component inside the NetBeans environment! :D). Of course, if you use External Execution, there is a separate VM and so a separated ClassLoader, but in this case, you have the option to configure the working directory. But the settings for OJB.properties system variable should work too... Ah, a lamp has turn on in my mind: may be NetBeans is putting their own classpath in from of your filesystem jars... In this case, you can have trouble with conflicts or buggy XML parsers, ant, servlet, and so on (the ones used by default in NetBeans sometime are little old - as example, the latest NetBeans still came with Tomcat 4.0.6). Best regards, Edson Richter Hi Aamir, first, the following lines can be completely nonsense (never used Netbean, don't have a clue in ClassLoader problematic ;-)) But this sounds like a typical ClassLoader problem. On OJB startup the classes specified in OJB.properties file are loaded. Maybe the OJB config files or/and OJB jars use wrong/different ClassLoader. Maybe you need to notify netbean to include OJB jars(+ used jars) in Internal Execution mode ClassLoader, or you need to move this jars in a directory included by the netbeans Internal ClassLoader. Or does netbeans read the jars two times by different ClassLoader. regards, Armin Muhammad Aamir wrote: Well, I develop and setup my small test application from scratch. There is one persistent class, a Test class which has main method, OJB.properties, repository.xml and repository.dtd. It all goes well but when I change Executor to Internal Execution it generates some warnings and exceptions as follows: [BOOT] WARN: Value org.apache.ojb.broker.cache.ObjectCacheDefaultImpl is illegal for key ObjectCacheClass (should be a class, using default value class org.apache.ojb.broker.cache.ObjectCacheDefaultImpl) [BOOT] WARN: Value org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl is illegal for key ConnectionFactoryClass (should be a class, using default value class org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.LockManagerDefaultImpl is illegal for key LockManagerClass (should be a class, using default value class org.apache.ojb.odmg.locking.LockManagerDefaultImpl) [BOOT] WARN: Value org.apache.ojb.odmg.locking.InMemoryLockMapImpl is illegal for key LockMapClass (should be a class, using default value class org.apache.ojb.odmg.locking.PersistentLockMapImpl) [BOOT] WARN: Value org.apache.ojb.broker.util.logging.PoorMansLoggerImpl is illegal for key LoggerClass (should be a class, using default value class org.apache.ojb.broker.util.logging.PoorMansLoggerImpl) [BOOT] WARN: Value org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessI mpl is illegal for key PersistentFieldClass (should be a class, using default value class org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessIm pl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerImpl is illegal for key PersistenceBrokerClass (should be a class, using default value class org.apache.ojb.broker.core.PersistenceBrokerImpl) [BOOT] WARN: Value org.apache.ojb.odmg.collections.DListImpl_2 is illegal for key OqlCollectionClass (should be a class, using default value class org.apache.ojb.odmg.collections.DListImpl) [BOOT] WARN: Value org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl is illegal for key PersistenceBrokerFactoryClass (should be a class, using default value null) [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object java.lang.ExceptionInInitializerError at org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker( Unknown Source) at kict.Test.main(Test.java:11
Re: Fwd: Using a non-existent collection inside a query
i saw the sample code you posted some days ago. now it's clear how you do it. The first step ;-) ojb needs this field (better: the collection referenced by this field) to handle the m:n-implementors in case of an m:n-relationship. That's just the case. If I use the artifact of virtual, the real field is no needed. It will never be read neither writeen to database. Just referenced when querying the database. afaik this should only be done if getCascadeStore() is true. imo the method storeCollections() needs some refactoring to separate handling of m:n-implementors, but that's another issue. The setting of the keys in referenced objects are occurring always. That why I need to put the line with if command in PersistenceBrokerImpl storeCollections method. I've not tried this with M:N, but sometime in the future I will check it (as far as the users get accostumed with this kind of facility, they wants more!). jakob Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
i do not see where this happens ?
Here (note: the if(!true.equals( bellow is in my patched version of OJB that is
working
fine):
...
private void storeCollections(Object obj, Vector vecCds) throws
PersistenceBrokerException
{
// get all members of obj that are collections and store all their elements
Iterator i = vecCds.iterator();
while (i.hasNext())
{
CollectionDescriptor cds = (CollectionDescriptor) i.next();
if(!true.equals(cds.getAttribute(virtual))) {
Object col = cds.getPersistentField().get(obj);
Collection currentMtoNKeys = null;
if (col == null)
{
if (cds.isMtoNRelation())
{
deleteMtoNImplementor(cds, obj);
}
}
...
Edson Richter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
Interesting is that this code is right (will only occur if cds.getCascadeStore()
returns true):
private void storeCollectionObject(CollectionDescriptor cds, Object otherObject)
{
// if cascade store: store associated object
if (cds.getCascadeStore())
{
store(otherObject);
}
else
{
if(logger.isEnabledFor(Logger.INFO)) logger.info(Cascade store for this
collection-descriptor ( + cds.getAttributeName()
+ ) was set to false.);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
Really, executing again withou my patch, I've seen that is not the keys, but the field it self. Sorry... The line getting in trouble is Object col = cds.getPersistentField().get(obj); because there is no persistent field at all. I'm a bit lost in too much code, techs, newbie programmers, and so on here... I think 1) if we use getCascadeDelete != true early, we can have trouble with M:N relationships; 2) if we use later, we get a non existent property exception because the field just don't exist in the bean. As far as I can see, this is the way the virtual attribute affect the OJB behavior. Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Using a non-existent collection inside a query
hi edson,
frankly, i'm still confused...
Sorry... I think I don't have sufficient english skills to make more clear...
i understand that collection-proxies do not seem to help because of the
way you built your gui :(
Thanks, I think you had some experiences (some good, some bad) with swing too... But
that's not our point, right ;-)
when you say the relationship does not exist, does this mean that it's
not defined in the repository ?
Yes, I mean that this is not defined in repository. Neither the collection-descriptor,
neither the field used when querying.
what do you mean by mounting the query ?
Imagine the object:
public class Customer {
public Integer id;
public String name;
}
Now I load some class that will notify (internally, in my app) that a new table is
avaliable
in database (the documents table), and I can make queries by the document number. But I
don't have a document neither documentNumber in Customer class.
To query I must do
Criteria c = new Criteria();
c.addEqualTo(document.documentNumber, 12345);
But OJB will throw exception: where is no document field in Customer. So I add
dinamically a
document field as an collection descriptor. Uau, OJB now queries the database! Fine
that's
all I want.
But, when I tried to store any Customer object, OJB throw an exception saying that
there is
no document field. Even if I use proxies=true (or not), lazy=true (or not),
auto-update=false (or not) and so on. Nothing works. Always exception.
I've detected that the problem is because OJB is trying to set key fields in referenced
objects (including my document collection - that doesn't exists at all, is just an
artifact
to make queries) - before storing...
what other parts of ojb did you need to modify to achieve this behaviour ?
None. Just that if does the job. I had think a lot about this, and I get the
conclusion that
OJB should not set keys in referenced object when auto-update=false, right? Or not?
As long as I don't want do change any default behavior of OJB, I've created the virtual
attribute, and used it...
Thanks again,
Edson Richter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Persisting Date and Time
You could use either TIMESTAMP and DATE (note that TIMESTAMP will maintain date and time). You object should use java.util.Date, and you must specify a conversion ... in XML field descriptor. Just double check mail list archives, there are a lot of info about this (even docs)... Best regards, Edson Richter MGR Informática Ltda Hi Fabiano, Try JDBC-TYPE='TIMESTAMP' - and try and use java.sql.Date instead of java.util.Date... I have run into problems before with java.util.Date but YMMV. Good Luck, Rob :) -Original Message- From: Fabiano Fernandes de Souza [mailto:[EMAIL PROTECTED] Sent: Thursday, 8 January 2004 2:08 a.m. To: [EMAIL PROTECTED] Subject: Persisting Date and Time I got in a value object a property named recDate of java.util.Date. It's mapped in resource.xml as jdbc-type=DATE and mapped in the ddl as rec_date TIMESTAMP. I persist the object with the current Date using something like: setRecDate(new Date()) and then I persist it using ODMG. Everything goes fine but in the table keeps registered only the date (not date and time) like this: 2004-01-06 00:00:00 What can I do to register the date and the time too? Thanks. -- Fabiano F. Souza Tecnologia da Informação Estudar Soluções em Treinamento Corporativo. (31) 32849294 - [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: AW: ClassPersistenceNotCapableException: java.lang.Integer not found ...
Look, as you defined field-descriptor id=4 name=intActivityIdFK column=ACTIVITY_ID jdbc-type=INTEGER / you can't have (or you will always get ClassCastException!!!) reference-descriptor name=intActivityIdFK class-ref=de.premiere.plato.app.activity.entity.ActivityModel refresh=true auto-retrieve=true foreignkey field-id-ref=4 / /reference-descriptor But you can create an attribute intActivityIdFk (of type int) AND activityFk (of type ActivityModel) in your beean, and your class descriptor should be like (and this should work fine) class-descriptor class=de.activity.entity.ModuleModel table=TMODULE field-descriptor id=1 name=intModuleAssignedId column=MODUL_ASSIGNED_ID jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=intModuleId column=MODUL_ID jdbc-type=INTEGER / field-descriptor id=3 name=strModuleExclusive column=SIMULTAN_WORK jdbc-type=CHAR / field-descriptor id=4 name=intActivityIdFK column=ACTIVITY_ID jdbc-type=INTEGER / reference-descriptor name=activityFK class-ref=de.premiere.plato.app.activity.entity.ActivityModel refresh=true auto-retrieve=true foreignkey field-id-ref=intActivityIdFk / /reference-descriptor /class-descriptor Best regards, Edson Richter Thanks for your answer. When I change the reference name to I get a MetadataException which states that it can't find a member in de.plato.app.activity.entity.ModuleModel. Of course there is no member in this class since I declared all attributes already in the class-descriptor. Any idea? Dirk -Ursprüngliche Nachricht- Von: João Vieira da Luz [mailto:[EMAIL PROTECTED] Gesendet: Montag, 29. Dezember 2003 19:51 An: 'OJB Users List' Betreff: RE: ClassPersistenceNotCapableException: java.lang.Integer not found ... Vertraulichkeit: Persönlich I think your problem is in the name of the reference-descriptor it has the same name that field 4. Try to change the name and I think it will work fine. -Original Message- From: Dirk Manske (Service Respond) [mailto:[EMAIL PROTECTED] Sent: segunda-feira, 29 de Dezembro de 2003 18:43 To: [EMAIL PROTECTED] Subject: ClassPersistenceNotCapableException: java.lang.Integer not found ... Sensitivity: Personal Hi, Can someone tell me how to set a reference-descriptor for a foreign key? Below is an excerpt of my repository-user.xml file. I always get the error message: ClassPersistenceNotCapableException: java.lang.Integer not found in repository.xml ... I have no clue what to do. Thx, Dirk class-descriptor class=de.activity.entity.ActivityModel table=TPACTIVITY field-descriptor id=1 name=intActivityId column=ACTIVITY_ID jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=strActivityName column=ACTIVITY_NAME jdbc-type=CHAR / /class-descriptor class-descriptor class=de.activity.entity.ModuleModel table=TMODULE field-descriptor id=1 name=intModuleAssignedId column=MODUL_ASSIGNED_ID jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=intModuleId column=MODUL_ID jdbc-type=INTEGER / field-descriptor id=3 name=strModuleExclusive column=SIMULTAN_WORK jdbc-type=CHAR / field-descriptor id=4 name=intActivityIdFK column=ACTIVITY_ID jdbc-type=INTEGER / reference-descriptor name=intActivityIdFK class-ref=de.premiere.plato.app.activity.entity.ActivityModel refresh=true auto-retrieve=true foreignkey field-id-ref=4 / /reference-descriptor /class-descriptor - 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: OQLQuery being cached? [orb newbie]
Are you working with DefaultCacheImpl or EmptyCacheImpl? If you are working with DefaultCacheImpl, take a look at config parameters. Otherwise, are there any exceptions (stack trace), messages (they can be very usefull if you enable higher level of logging as DEBUG). Best regards, Edson Richter Hi, I am executing the following code: OQLQuery query = impl.newOQLQuery(); query.create( [THEQUERY] ); DList results = (DList)query.execute(); Iterator iterator = results.iterator(); If I change some column with an external tool and then execute the code, the updated column is not reflected in the orb objects. Is there a config value or a runtime parameter that I need to change? What is going on behind the scenes here? Thanks for your help, K. - 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: OQLQuery being cached? [orb newbie]
In real, I'm not an specialist in caches ;), but I've used with success object-cache .. tag inside class-descriptor, no elsewhere. I think I've read somewhere that is possible to configure the object-cache for the connection (or the alias), but I never reade more, and now I'm not sure. Give a try to DTD doc. Is the first place I look when in doubt. Best regards, Edson Richter Thanks for your quick answer, I cheched the OJB.properties file an I was using DefaultCacheImpl I change it to ObjectCacheEmptyImpl and now it is working as I was expecting. Now just to learn the reasons for the previous behaviour: A comment in OJB.properties: # The ObjectCacheClass entry tells OJB which concrete ObjectCache # implementation is to be used as standard cache. # Its also possible to override this entry adding object-cache elements # on jdbc-connection-descriptor level and # per class-descriptor in repository file In my repository_internal.xml I have the following line: object-cache class=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl /object-cache Why it wasn't working as I was expecting? Where is the documentation about the config parameters for the cache implementations? Thanks for your help, K. [EMAIL PROTECTED] wrote: Are you working with DefaultCacheImpl or EmptyCacheImpl? If you are working with DefaultCacheImpl, take a look at config parameters. Otherwise, are there any exceptions (stack trace), messages (they can be very usefull if you enable higher level of logging as DEBUG). Best regards, Edson Richter - 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]
OJB Rc4 freeze
Hi! I'm working on a OJB Rc4 I've downloaded (and compiled) source code from CVS about 2 or 3 weeks ago. I've created a class with two children classes (two extends one). I've declared a class-descriptor for the parent class, with extents for the two childs, and then declared the class-descriptor for one child class, and I forgot to declare the second one. OJB gives no error when starting, and when I tryied to load instances of the second class (througt a QueryByCriteria), OJB freeze (infinite loop) when I issue getCollectionByQuery without any error. I think it's a (minor) bug on OJB (the fact it not check if all extents are declared), and I really don't know even if it's already fixed on latest sources. Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
