Re: Stability
Hi JohnE,
johne wrote:
In response to below, it worked in 1.0.3 and then 1.0.4. When I
tried 1.0.5 it failed. I backed off to 1.0.4 again and it works. In
all cases I use the same latest MySql database driver. No other
changes other then the change in OJB version.
It's weird! I try to reproduce your issue without success. The query
include a class 'Person' and looks like this:
Criteria crit = new Criteria().addLike("firstname", "%o%")
.addAndCriteria(new Criteria().addLike("lastname", name));
ReportQueryByCriteria q = QueryFactory.newReportQuery(Person.class, crit);
q.setAttributes(new String[]{"id", "firstname", "count(id)"});
q.addGroupBy(new String[]{"id", "firstname"});
q.addOrderByAscending("firstname");
The field 'id' is mapped as Integer in the Person class-descriptor.
In the result set array the 'count(id)' column is returned as Integer
and NOT as String (using hsql and mysql). Could you give me a hint how
to reproduce your issue?
regards,
Armin
JohnE
Armin Waibel wrote:
johne wrote:
In first testing the 1.0.5 RC, I get the error below. This
worked as is in 1.0.4. Something different with the count use in
the RC?
Caused by: java.lang.ClassCastException: java.lang.String cannot
be cast to java.lang.Long which comes from this line as shown in
more detail below: count = new
Integer(((Long)obj[2]).intValue());
This came out of getting a count out of a ReportByCriteria result
set.
Where the columns look like: private static final String[]
crColumns = new String[]{"countryId", "regionId",
"count(countryId)","count(regionId)"}; ReportQueryByCriteria
query = new
ReportQueryByCriteria(specificActiveServiceLocationQueryVO,
crColumns, crit, true); . . obj = (Object[])
resultsIt.next(); count = new Integer(((Long)obj[2]).intValue());
This could be jdbc-driver issue. If OJB doesn't know the field
(detect a not mapped field), in your case the count(...) field, the
jdbc-type is resolved by using the ResultSet metadata
(rsMetaData.getColumnType(...)) of the jdbc-driver.
You can try to use the query.setJdbcTypes method to specify the
sql-types, then OJB resolves the proper java-jdbc-types
http://db.apache.org/ojb/docu/guides/jdbc-types.html
int types[] = new int[]{Types.DECIMAL, Types.VARCHAR,
Types.BIGINT}; ReportQueryByCriteria q =
QueryFactory.newReportQuery(Person.class, crit);
q.setAttributes(new String[]{"id", "firstname", "count(*)"});
q.setJdbcTypes(types);
This should work for all none mapped query fields. If the field is
mapped the type setting will be ignored - this is a bug and will
be fixed in 1.0.5rc2.
regards, Armin
- JohnE
http://jobbank.com/ jobbank.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
- JohnE
http://jobbank.com/ jobbank.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stability
johne wrote:
In first testing the 1.0.5 RC, I get the error below. This worked as is in
1.0.4. Something different with the count use in the RC?
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
java.lang.Long which comes from this line as shown in more detail below:
count = new Integer(((Long)obj[2]).intValue());
This came out of getting a count out of a ReportByCriteria result set.
Where the columns look like:
private static final String[] crColumns = new String[]{"countryId",
"regionId", "count(countryId)","count(regionId)"};
ReportQueryByCriteria query = new
ReportQueryByCriteria(specificActiveServiceLocationQueryVO,
crColumns, crit, true);
.
.
obj = (Object[]) resultsIt.next();
count = new Integer(((Long)obj[2]).intValue());
This could be jdbc-driver issue. If OJB doesn't know the field (detect a
not mapped field), in your case the count(...) field, the jdbc-type is
resolved by using the ResultSet metadata (rsMetaData.getColumnType(...))
of the jdbc-driver.
You can try to use the query.setJdbcTypes method to specify the
sql-types, then OJB resolves the proper java-jdbc-types
http://db.apache.org/ojb/docu/guides/jdbc-types.html
int types[] = new int[]{Types.DECIMAL, Types.VARCHAR, Types.BIGINT};
ReportQueryByCriteria q = QueryFactory.newReportQuery(Person.class, crit);
q.setAttributes(new String[]{"id", "firstname", "count(*)"});
q.setJdbcTypes(types);
This should work for all none mapped query fields. If the field is
mapped the type setting will be ignored - this is a bug and will be
fixed in 1.0.5rc2.
regards,
Armin
-
JohnE
http://jobbank.com/ jobbank.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stability
Hi JohnE, johne wrote: We may actually have to go with the 1.0.5 release in production because of our desire to use one of the newer features. The last RC came out 29JAN2008 with the last code changes in subversion on 30JAN2008, so the RC1 does not contain some fixes. Is there anything you consider important to get into the RC prior to it being considered "safe enough for use"? As we use the PB API the only issues that might stop us are: http://issues.apache.org/jira/browse/OJB-143 This issue affects 1.0.4 too, so you already have to deal with it. http://issues.apache.org/jira/browse/OJB-142 <- Likely not so important to us. This will be fixed in 1.0.5 RC2 Is there anything else that prevent the current version from use? If your own tests pass with 1.0.5rc1 there is no reason to prevent from use. The OJB test-suite contains a lot of tests (all tests from 1.0.4 + many new tests) and 1.0.5rc1 pass all tests (except the known issues). Explored 1.0.5rc1 bugs: http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html regards, Armin Looking at the release notes, it appears that we just need to change out the properties file and the dtd. Some properties have changed, but as we use the default current 1.0.4 properties in file mostly, I am not sure we would notice changes. Has anybody else had difficulties or successes with this in a production environment? We use Maven, so it is a bit of an aggravation manually pushing in the library, but appreciative users like myself should not be so picky. Thanks for your ideas. - JohnE http://www.jobbank.com jobbank.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using OJB with iAnywhere driver to connect to Sybase
Hi Jenish, Jenish wrote: Hello All, We have a project which uses OJB to talk with DB. It was working fine with jconnect driver. Now we have changed our design and now we are trying iAnywhere driver instead of jConnect2. Now we are facing the problem that after some time of deployment we are getting exception at the backend something like "Borrow broker from pool failed" Can anybody please suggest me if we need to tune some parameter of OJB to make it run with iAnywhere? This error indicate that the broker pool exhaust (too many concurrent clients access OJB, you can increase the broker pool via OJB.properties file) or that your "new design" cause a PersistenceBroker leak (somewhere in your code a broker.close() statement is missed). Please search the OJB-user list for more details: http://marc.info/?l=ojb-user&w=2&r=1&s=broker+leak&q=b regards, Armin Thanks, Jenish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it Possible to Update Inheritance Hierarchies?
Hi Cleverson, Schmidt wrote: Hi, Considerer the following hierarchy: Person <- Employee <- Boss Each class is maped to a distinct table (Mapping Classes on Multiple Joined Tables) In this case, if I create an employee, two records are persisted in the DB (1 person and 1 employee). What if this employee is promoted to a boss? How can we update the hierarchy including just 1 new record at the end of the chain? I've tried, but the whole chain is created again. Is it possible to instruct OJB to just "append" 1 record at the Boss table? Sorry no! It's a new Boss object, so OJB creates the whole hierarchy with the new Boss object identity. regards, Armin Anyone here ever faced the same issue? Thanks in advance! Cleverson Schmidt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling Large Resultset in Oracle
Hi Paul, Somendra Paul wrote: Hi Armin This SQL query we have is not a data only from one table, but is a very big SQL query looks like following: select a,b,c from x,y,z where union all select a,b,c from x,y,z where union all select a,b,c from x,y,z This is a generic SQL written but the our SQL looks is on similar lines. Do your solutions mentioned of report queries will solve this kind of issues ? The report query can handle all OJB Criteria based queries and from 1.0.5 it also possible to execute generic SQL via Report queries (more details see 1.0.5 documentation). regards, Armin We might think of 1.5 , depending upon what you say. Thanks and Regards, Somendra Paul. - Original Message From: Armin Waibel <[EMAIL PROTECTED]> To: OJB Users List Sent: Sunday, September 21, 2008 9:05:06 PM Subject: Re: Handling Large Resultset in Oracle Hi Paul, Somendra Paul wrote: Hi All, I am using OJB1.4 against Oracle10g with classes12.jar. We are trying to export data from the DB, using SQL query which returns 60 records , what we found out that is when we do iterator = query.getIteratorByQuery(),and iterate over the results, we find that after iterating over 30 records, the VM grows rapidly and the entire program crashes giving OOM errors, where as when we used simple JDBC program to implement it, we saw that the entire 600K records were extracted using only 160mb of memory , and the ojb execution takes more than 1.5gb to execute before crashing. Do we know how to solve this memory issue when executing large resultset in Oracle. One solution that in the OJB archives for ProgressSQL is that to use fetchSize= , it will solve this issue ??? The problem could be the cache. Dependent on the used cache OJB keep all materialized objects (or copies of these objects) in memory. Most cache implementations use soft-references (so OOM errors shouldn't occur) but maybe your objects have complex relationships or your layer holds hard-references to the materialized objects. You can try to evict the cache while iterate the result set. If you don't rely on the materialized java objects you can use a report query http://db.apache.org/ojb/docu/guides/query.html#Report+Queries to iterate over the result set (returns a collection of arrays). This bypass the cache and should result in a memory-use comparable with a plain jdbc-query. The upcoming OJB 1.0.5 has enhanced query features and supports limit and pagination of query results (Oracle is supported) - 1.0.5rc1: http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html The query-guide of the included documentation show how to use this feature. regards, Armin Thanks and Regards Somendra Paul. - 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: Handling Large Resultset in Oracle
Hi Paul, Somendra Paul wrote: Hi All, I am using OJB1.4 against Oracle10g with classes12.jar. We are trying to export data from the DB, using SQL query which returns 60 records , what we found out that is when we do iterator = query.getIteratorByQuery(),and iterate over the results, we find that after iterating over 30 records, the VM grows rapidly and the entire program crashes giving OOM errors, where as when we used simple JDBC program to implement it, we saw that the entire 600K records were extracted using only 160mb of memory , and the ojb execution takes more than 1.5gb to execute before crashing. Do we know how to solve this memory issue when executing large resultset in Oracle. One solution that in the OJB archives for ProgressSQL is that to use fetchSize= , it will solve this issue ??? The problem could be the cache. Dependent on the used cache OJB keep all materialized objects (or copies of these objects) in memory. Most cache implementations use soft-references (so OOM errors shouldn't occur) but maybe your objects have complex relationships or your layer holds hard-references to the materialized objects. You can try to evict the cache while iterate the result set. If you don't rely on the materialized java objects you can use a report query http://db.apache.org/ojb/docu/guides/query.html#Report+Queries to iterate over the result set (returns a collection of arrays). This bypass the cache and should result in a memory-use comparable with a plain jdbc-query. The upcoming OJB 1.0.5 has enhanced query features and supports limit and pagination of query results (Oracle is supported) - 1.0.5rc1: http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html The query-guide of the included documentation show how to use this feature. regards, Armin Thanks and Regards Somendra Paul. - 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: Blobs
Hi John, the LOB-support of OJB 1.0.4 is very rudimentary (AFAIK OJB always expects that LOB's are byte[] or String fields on java object level). The upcoming OJB 1.0.5 have more experienced LOB-support (don't remind me that I announced the release long ago ;-)). I recommend to give OJB 1.0.5RC1 a try (mysql blobs are supported): http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html In the included documentation you can find a new howto about LOB's. regards, Armin johne wrote: Been doing a lot of development lately implementing our document repository. Specifics include OJB 1.0.4 and MySql 5.0 with a fairly recent driver. We were using LONGVARCHAR to represent long textual information, but was hoping to make it a bit more generic by changing over to using a BLOB. Our mapping is: Basically our DocumentContentVO contains just the two attributes: public Long docId; public java.sql.Blob content; With the appropriate getters and setters. The MySql database has a nullable content column of type blob. We were going to use javax.sql.rowset.serial.SerialBlob to add Blobs back into the database, but it never gets this far. It throws an exception when it attempts to use our mapping to this object above in an initial query. We get the following error: Exception: IllegalAccess error setting field:content in object:com.comp.prod.model.document.DocumentContentVO host=0:0:0:0:0:0:0:1: org.apache.ojb.broker.metadata.MetadataException: IllegalAccess error setting field:content in object:com.comp.prod.model.document.DocumentContentVO at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectImpl.setValueFor(Unknown Source) at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectImpl.set(Unknown Source) at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.buildOrRefreshObject(Unknown Source) at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readObjectFrom(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source) at org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) Caused by: java.lang.IllegalArgumentException: Can not set java.sql.Blob field com.comp.prod.model.document.DocumentContentVO.content to [B at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146) at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150) at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) at java.lang.reflect.Field.set(Field.java:657) ... 79 more Any ideas? Thanks as usual. John - JohnE http://www.jobbank.com jobbank.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to hide database user and password
Hi Frank, Hiller, Frank RD-PT31 wrote: I'm using PB version 1.0.3. Database user and password are in repository_database.xml. How can one hide usr + pwd? I'd prefer to have placeholders there and set both in source code. http://db.apache.org/ojb/docu/faq.html#userPasswordNeeded If you like to the convenience method to lookup a PB instance for one PBKey (user, pwd combination) - PBF.defaultPersistenceBroker(), you can set the PBKey in the PBF with PersistenceBrokerFactory#setDefaultKey at start of our application. Sorry but I don't remember if this works for version 1.0.3 ditto - give it a try. regards, Armin Thanks...Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB Development Activity
Hi Jason, Jason wrote: I have been away from the OJB community for a few years. Based on the state of the website and the SVN repository, it looks like this project has stalled... the last commits were months ago and the last release was in 2005. Is OJB dead, or is active work being done somewhere to work towards finishing 1.1, 2.0, the OTM, et al. Sorry for the delay. I took a few "sabbatical weeks" from OJB to spend more time with my (newborn) daughter and currently I have some problems with my eyes, which makes it difficult to work on OJB. I will continue the work on OJB ASAP to prepare OJB 1.0.5_RC2. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question about storing objects
Abid Hussain wrote:
Hi Armin,
thanks for help.
Just to be sure that I got the point: When there is a 'proxy="dynamic"'
in the class-descriptor, proxies are always used when more than one
object is queried?
The returned persistence capable object is always a proxy object, even
if the query result returns a single object.
In my opinion using a proxy on class-descriptor level (persistence
capable object proxy) doesn't give much advantage, because OJB always
perform the full query and only materialize the object identity from the
result set.
I thought that proxies are only used when retrieving a collection
through a relation (1:n or m:n, e.g. ShoppingCart.getArticles() - see
below)...
If you declare proxy="true" on collection-/reference-descriptor level
(1:1, 1:n or m:n relation) then yes you are right.
regards,
Armin
Regards,
Abid
Armin Waibel schrieb:
Hi Abid,
Abid Hussain wrote:
Hi again,
I think this issue has to something with the materialization of
objects (when using proxies). But I thought that proxies are only
used, when retrieving a corresponding collection of an object (in 1:n
and m:n relations, e.g. ShoppingCart.getArticles()...).
What I'm doing when using findAll() (see below) is something like
SELECT * FROM . I thought, in this case no proxies are
used???
You are using dynamic proxies for all Account_2 objects:
The query result collection isn't a proxy object. Instead each result
object is a proxy object of persistence capable object (Account_2
object). In most cases this doesn't have an performance advantage.
If you now store each of these objects without materialization (e.g.
your log.debug() force the materialization of the object) OJB thinks
that the object didn't change and skip the update.
regards,
Armin
Regards,
Abid
Abid Hussain schrieb:
Hi everybody,
I have written a storeAll()-method in a dao to store all given
objects in one transaction (you find the code at the end of this mail).
Now please have a look at the following lines of code:
Account_2DAO dao1 = new Account_2DAO("DB1");
Collection accounts = dao1.findAll(Account_2.class);
logger.debug(accounts);
Account_2DAO dao2 = new Account_2DAO("DB2");
dao2.storeAll(accounts);
As you see, that there are two daos initialized. The first (dao1)
retrieves all objects (using findAll()) from a database (DB1). The
second (dao2) stores all retrieved objects into another database (DB2).
The findAll()-method works fine.
But the storeAll()-method only works when the line of code
logger.debug(accounts);
is called. If not, no data is inserted.
Any ideas what's going wrong (you find the class-descriptor file
below)?
Regards,
Abid
Code of storeAll():
public void storeAll(Collection valueObjects)
throws PersistentStoringException {
if (valueObjects != null) {
try {
broker.beginTransaction();
for (T valueObject : valueObjects) {
broker.store(valueObject, ObjectModification.INSERT);
}
broker.commitTransaction();
} catch (Exception e) {
broker.abortTransaction();
throw new PersistentStoringException(
"Error while storing objects.\n" + e);
} finally {
if (broker != null && !broker.isClosed())
broker.close();
}
}
}
Class-descriptor of Account_2:
-
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: How open 2 different Databases ?ope
Hi Hans, Hans Novak wrote: Hi, my prg works fine with ojb. But now i have to open 2 different Databases (on the same host), because i want to import/export something. How can i do that ? I have only one "build.properties" file !? OJB can handle different DB at the same time: http://db.apache.org/ojb/docu/faq.html#multipleDB The automatic creation of the database tables and OJB config files is only possible for one DB at the same time. regards, Armin Hans - 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: Database Update
Hi Hans, Hans Novak wrote: Hi, how can i update the Database, if i change my Java-sourcecode and with that the database structure, without loosing any data. Until now i use the mysql command to import the SQL-Ascii File, created from OJB with ant. But this deletes first all tables. The upcoming version of OJB 1.0.5 use DdlUtils instead of Torque to generate the tables of the unit tests. DdlUtils supports alteration of tables - maybe this can help to solve your problem. http://db.apache.org/ddlutils/documentation.html regards, Armin Hans - 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: OJB 1.0.4, Oracle 10g and LONGVARCHAR column issue
Hi Vasily, could you please open an issue on OJB-JIRA http://issues.apache.org/jira/browse/OJB and add a detailed description about how to reproduce the issue (then I'm able to write a test case). regards, Armin Vasily Ivanov wrote: Hello, I'm using Oracle 10.2.0.4.0 thin Jdbc driver, Oracle 10g db, Ojb 1.0.4, Tomcat 4, c3p0 connection pooling, Spring/Spring Modules. I'm experiencing a problem materializing an object with LONGVARCHAR field (LONG datatype in Oracle). Caused by: java.sql.SQLException: Stream has already been closed at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208) at oracle.jdbc.driver.LongAccessor.getBytes(LongAccessor.java:151) at oracle.jdbc.driver.LongAccessor.getString(LongAccessor.java:193) at oracle.jdbc.driver.T4CLongAccessor.getString(T4CLongAccessor.java:426) at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl.java:403) at com.mchange.v2.c3p0.impl.NewProxyResultSet.getString(NewProxyResultSet.java:3316) at org.apache.ojb.broker.metadata.JdbcTypesHelper$T_LongVarChar.readValueFromResultSet(JdbcTypesHelper.java:449) at org.apache.ojb.broker.metadata.JdbcTypesHelper$BaseType.getObjectFromColumn(JdbcTypesHelper.java:331) at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readValuesFrom(RowReaderDefaultImpl.java:246) at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readObjectArrayFrom(RowReaderDefaultImpl.java:208) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:457) at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:278) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:131) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:263) at org.apache.ojb.broker.core.QueryReferenceBroker.doRetrieveCollection(QueryReferenceBroker.java:764) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:722) at org.apache.ojb.broker.core.QueryReferenceBroker.doRetrieveCollections(QueryReferenceBroker.java:973) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:940) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(RsIterator.java:488) at org.apache.ojb.broker.accesslayer.RsIterator.next(RsIterator.java:278) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(PersistenceBrokerImpl.java:1770) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(DelegatingPersistenceBroker.java:352) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(DelegatingPersistenceBroker.java:352) at org.springmodules.orm.ojb.PersistenceBrokerTemplate$2.doInPersistenceBroker(PersistenceBrokerTemplate.java:187) at org.springmodules.orm.ojb.PersistenceBrokerTemplate.execute(PersistenceBrokerTemplate.java:141) Oracle documentation reads that: "If you try to access the data for the none-stream column before reading the data from the streaming column the JDBC driver discards the streaming data automatically. You cannot access that data any more. If you try to get a stream for the LONG column the driver raises a "Stream Closed" error." Even if LONGVARCHAR field is specified first in the list of field-descriptors OJB ignores that and tries to get none-stream PK fields first (see method RsIterator#getObjectFromResultSet() which calls RowReaderDefaultImpl#readPkValuesFrom()) and only than it tries to get LONGVARCHAR column and fails because stream has already been invalidated by Oracle driver at that point. I have no idea how to get around this problem. The only solution I can think about is providing my own implementation of RowReaderDefaultImpl for that particular class. Surprisingly enough it works fine if I change connection pooling from c3p0 to commons dbcp... Maybe DBCP silently swallows "Stream has already been closed" SQLException? I haven't looked into there yet. Thank you, Vasily - 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: question about storing objects
Hi Abid,
Abid Hussain wrote:
Hi again,
I think this issue has to something with the materialization of objects
(when using proxies). But I thought that proxies are only used, when
retrieving a corresponding collection of an object (in 1:n and m:n
relations, e.g. ShoppingCart.getArticles()...).
What I'm doing when using findAll() (see below) is something like SELECT
* FROM . I thought, in this case no proxies are used???
You are using dynamic proxies for all Account_2 objects:
The query result collection isn't a proxy object. Instead each result
object is a proxy object of persistence capable object (Account_2
object). In most cases this doesn't have an performance advantage.
If you now store each of these objects without materialization (e.g.
your log.debug() force the materialization of the object) OJB thinks
that the object didn't change and skip the update.
regards,
Armin
Regards,
Abid
Abid Hussain schrieb:
Hi everybody,
I have written a storeAll()-method in a dao to store all given objects
in one transaction (you find the code at the end of this mail).
Now please have a look at the following lines of code:
Account_2DAO dao1 = new Account_2DAO("DB1");
Collection accounts = dao1.findAll(Account_2.class);
logger.debug(accounts);
Account_2DAO dao2 = new Account_2DAO("DB2");
dao2.storeAll(accounts);
As you see, that there are two daos initialized. The first (dao1)
retrieves all objects (using findAll()) from a database (DB1). The
second (dao2) stores all retrieved objects into another database (DB2).
The findAll()-method works fine.
But the storeAll()-method only works when the line of code
logger.debug(accounts);
is called. If not, no data is inserted.
Any ideas what's going wrong (you find the class-descriptor file below)?
Regards,
Abid
Code of storeAll():
public void storeAll(Collection valueObjects)
throws PersistentStoringException {
if (valueObjects != null) {
try {
broker.beginTransaction();
for (T valueObject : valueObjects) {
broker.store(valueObject, ObjectModification.INSERT);
}
broker.commitTransaction();
} catch (Exception e) {
broker.abortTransaction();
throw new PersistentStoringException(
"Error while storing objects.\n" + e);
} finally {
if (broker != null && !broker.isClosed())
broker.close();
}
}
}
Class-descriptor of Account_2:
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unexpected result
Hi,
johne wrote:
Hey all,
Been a while since I had need to post. I am looking forward to the new
release as I am still on 1.0.3. Thank you for all of the hard work Armin.
Using 1.0.3, I am getting an unexpected result with one query using the PB.
I am using this query:
QueryByCriteria query = new QueryByCriteria(objectClass);
query.addOrderByAscending("productGroupId");
query.addOrderByAscending("country.name");
query.addOrderByAscending("region.name");
For this query, it is valid to have region names that are null. Despite
this, I would want those records to be included in the result set, but they
are not.
I setup a test similar to yours using latest from SVN (OJB_1_0_RELEASE
branch). The test first insert two Location instances with Region and
Country objects (allow OJB to cascade insert referenced objects). One
Region object has set name to NULL. The test looks like this:
String tmp = ojbTestMethodIdentifier();
String id_1 = tmp + "_1";
String id_2 = tmp + "_2";
Country cou_1 = new Country();
cou_1.setCountryId(id_1);
Region reg_1 = new Region();
reg_1.setCountryId(id_1);
reg_1.setRegionId("r1");
reg_1.setName(null);
Location loc_1 = new Location();
loc_1.setCountry(cou_1);
loc_1.setRegion(reg_1);
Country cou_2 = new Country();
cou_2.setCountryId(id_2);
cou_2.setName("cou_2");
Region reg_2 = new Region();
reg_2.setCountryId(id_2);
reg_2.setRegionId("r1");
reg_2.setName("reg_2");
Location loc_2 = new Location();
loc_2.setCountry(cou_2);
loc_2.setRegion(reg_2);
broker.beginTransaction();
broker.store(loc_1);
broker.store(loc_2);
broker.commitTransaction();
Criteria c = new Criteria();
QueryByCriteria query = QueryFactory.newQuery(Location.class, c, true);
query.addOrderByAscending("productGroupId");
query.addOrderByAscending("country.name");
query.addOrderByAscending("region.name");
Collection result = broker.getCollectionByQuery(query);
assertEquals(2, result.size());
The test pass!
The generated SQL:
INSERT INTO country_ (countryid_,name_)
VALUES ('_testQueryOrderBy_1207583603109__1','')
INSERT INTO region_ (countryid_,regionid_,name_)
VALUES ('_testQueryOrderBy_1207583603109__1','r1','')
INSERT INTO servicelocation_ (id_,productgroupid_,countryid_,regionid_)
VALUES ('21','','_testQueryOrderBy_1207583603109__1','r1')
INSERT INTO country_ (countryid_,name_)
VALUES ('_testQueryOrderBy_1207583603109__2','cou_2')
INSERT INTO region_ (countryid_,regionid_,name_)
VALUES ('_testQueryOrderBy_1207583603109__2','r1','reg_2')
INSERT INTO servicelocation_ (id_,productgroupid_,countryid_,regionid_)
VALUES ('22','','_testQueryOrderBy_1207583603109__2','r1')
SELECT DISTINCT A0.id_,A0.productgroupid_,A0.countryid_,A0.regionid_,
A1.name_ as ojb_col_5,A2.name_ as ojb_col_6 FROM servicelocation_ A0
INNER JOIN country_ A1 ON A0.countryid_=A1.countryid_
INNER JOIN region_ A2 ON A0.countryid_=A2.countryid_ AND
A0.regionid_=A2.regionid_
ORDER BY 2,5,6
So the issue seems to be fixed in upcoming OJB_1.0.5 or you are doing
something wrong (with OJB 1.0.3). Is column 'countryid' and 'regionid'
correctly set in table servicelocation?
You can trace generated SQL with P6Spy (included in OJB)
http://db.apache.org/ojb/docu/faq.html#traceProfileSQL
or log it by database.
regards,
Armin
I am using this mapping:
name="slId"
column="slid"
jdbc-type="BIGINT"
primarykey="true"
autoincrement="true"
/>
name="country"
class-ref="com.jmjmedia.sp.model.places.CountryVO"
auto-retrieve="true"
auto-update="none"
auto-delete="none"
proxy="false">
name="region"
class-ref="com.jmjmedia.sp.model.places.RegionVO"
auto-retrieve="true"
auto-update="none"
auto-delete="none"
proxy="false">
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating objects
Hi Abid, Abid Hussain wrote: Hi everybody, I've a table with quite a lot of columns. When using broker.update(object) all columns are updated. Is there a way to only update the columns which actually changed? I'm looking for something like UPDATE MyTable SET MyTableColumn = WHERE ID=xxx. Anyone got an idea? Sorry, with the current version of OJB this is not possible (next major version will support this). regards, Armin Regards, Abid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: Re: ObjectEnvelope’s modificat ion detection mechanism – “abort() after fl ush()”
Hi Mario, Mario Curcija wrote: Hi Armin, Thanks for replying. We are actually striving to upgrade from 1.0.1 to 1.0.4 (hopefully later to 1.0.5 as well). As I see ODMG API is not very popular among ojb-users. Today I checked Jira Issues tracking system again looking for a bug report regarding our problem, but I wasn’t able to find anything similar. Should I open one? Yes! This will remind me to fix this issue (and to note in the release notes) and you can comment my solution/ reopen the issue if necessary. I think you’ll have to renounce “reuse” strategy if you are concerned about performance in this case (after introduction of “initialImage”). Finally only “flush()” calls are affected by this problem. I try to avoid an additional image object. Locally I introduce an enumeration class WriteMode with three modes (commit, checkpoint, flush) and class ObjectEnvelope remember the current and last WriteMode. If now tx.commit() is called and an error occur OJB can check for the last WriteMode. If the last WriteMode is WriteMode.FLUSH OJB will evict the associated persistent object from the cache (this fix will the issue with performance impact). Think this is very similar to your suggestion but with WriteMode instances instead of an additional image object. Now the tests - testTransactionFlush() - testTransactionFlush_2() pass using ObjectCacheDefaultImpl (with autoSync=false). Hope I find the time to check in the changes and build a new 1.0.5RC during the next week. regards, Armin Best regards, Mario Curcija Armin Waibel <[EMAIL PROTECTED]> schrieb am 21.03.2008 03:42:13: Hi Mario, Mario Curcija wrote: Hi ojb-users, yesterday, I ran into a problem during testing against 1.0.5rc1. Many thanks for testing RC1! The following two tests: - testTransactionFlush() and - testTransactionFlush_2() (both coming from org.apache.ojb.odmg.ODMGRollbackTest) are failing when ObjectCacheDefaultImpl (with autoSync=false) is used as object-cache implementation instead of default one (“twoLevel”). Both tests are doing following: - persisting previously non-persisted objects by invoking Transaction.lock(Object, int) and calling TransactionExt.flush() afterwards, - performing Transaction.abort() and at last, - checking for existence of used objects (in DB/Cache) via org.apache.ojb.broker.query.QueryByIdentity expecting not to find them. In these tests objects were not evicted from cache as expected (on abort() call). I was hoping that problem was in usage of ObjectCacheSoftImpl as cache implementation but it turned out that that ObjectEnvelope’s modification detection mechanism doesn’t correctly supports “abort() after flush()” since ObjectEnvelope’s internal images (beforeImage and currentImage) are reused during subsequent flush() calls (please check following two methods: ObjectEnvelope.cleanup and ObjectEnvelope.hasChanged). You are absolutely right! It's a bug. Thanks for the detailed description (make it easy to reproduce the issue). We are experimenting with a workaround that makes use of an additional “initialImage” (reference to first beforeImage), that let's the hasChanged method detect changes with respect to “initialImage” correctly in the case when abort() is invoked after flush(). However, we are not sure, whether this might have other implications. Let me think about this (for a day or two). Another Image instance and detection of changes could have an impact on memory consumption and performance. regards, Armin On the other hand, the only reason why those two test-cases are running fine with default “twoLevel” as object-cache is while it implements PBStateListener interface and reacts on beforeRollback(PBStateEvent) by clearing session cache(thus removing newly created objects). - 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: Someone can help-me with my project?
Hi Andre, Andre_LAU wrote: Hello, I'm trying to generate the O/R Mapping information for my project using the XDoclet module. There is some syntax errors that I can't understand. Follow my project and the log generated: http://www.nabble.com/file/p16311031/java.rar java.rar http://www.nabble.com/file/p16311031/log01.txt log01.txt By default XDoclet 1.x doesn't support Generics, more precisely the xjavadoc.jar version shipped with XDoclet. More details here: http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-8243.html If you replace the xjavadoc-1.1.jar with the 1.5-snapshot version http://sourceforge.net/project/showfiles.php?group_id=31602 the generation of O/R mapping files should pass (requires xdoclet 1.2.2 or higher). regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ObjectEnvelope’s modification detect ion mechanism – “abort() after flush()”
Hi Mario, Mario Curcija wrote: Hi ojb-users, yesterday, I ran into a problem during testing against 1.0.5rc1. Many thanks for testing RC1! The following two tests: - testTransactionFlush() and - testTransactionFlush_2() (both coming from org.apache.ojb.odmg.ODMGRollbackTest) are failing when ObjectCacheDefaultImpl (with autoSync=false) is used as object-cache implementation instead of default one (“twoLevel”). Both tests are doing following: - persisting previously non-persisted objects by invoking Transaction.lock(Object, int) and calling TransactionExt.flush() afterwards, - performing Transaction.abort() and at last, - checking for existence of used objects (in DB/Cache) via org.apache.ojb.broker.query.QueryByIdentity expecting not to find them. In these tests objects were not evicted from cache as expected (on abort() call). I was hoping that problem was in usage of ObjectCacheSoftImpl as cache implementation but it turned out that that ObjectEnvelope’s modification detection mechanism doesn’t correctly supports “abort() after flush()” since ObjectEnvelope’s internal images (beforeImage and currentImage) are reused during subsequent flush() calls (please check following two methods: ObjectEnvelope.cleanup and ObjectEnvelope.hasChanged). You are absolutely right! It's a bug. Thanks for the detailed description (make it easy to reproduce the issue). We are experimenting with a workaround that makes use of an additional “initialImage” (reference to first beforeImage), that let's the hasChanged method detect changes with respect to “initialImage” correctly in the case when abort() is invoked after flush(). However, we are not sure, whether this might have other implications. Let me think about this (for a day or two). Another Image instance and detection of changes could have an impact on memory consumption and performance. regards, Armin On the other hand, the only reason why those two test-cases are running fine with default “twoLevel” as object-cache is while it implements PBStateListener interface and reacts on beforeRollback(PBStateEvent) by clearing session cache(thus removing newly created objects). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cache Issue in distributed environment
Armin Waibel wrote: I don't find information to configure it with OJB. Can anybody help me ? If you use OJB 1.0.5rc1 change the object-cache element within your jdbc-connection-descriptor to one global cache region: a cache region for each class: For version 1.0.4 specifiy the full qualified class name (e.g. org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl). You can configure the JCS cache via the cache.ccf properties file. Sorry, I have to clarify my last post. I would recommend to use the two level cache with the distributed cache as second level cache. If you use OJB 1.0.5rc1: OJB 1.0.4: attribute-value="org.apache.ojb.broker.cache.ObjectCacheJCSImpl"/> attribute-value="org.apache.ojb.broker.cache.ObjectCacheTwoLevelImpl$CopyStrategyImpl"/> regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cache Issue in distributed environment
Hi Cedric, Cédric Talon wrote: Hi, I am new on this mailing list and so it is my first message. welcome to this list! I am working on a project which is using OJB in a distributed environment. The distributed issue is my problem ! I have read there are important points to respect in this case. The first one is to use Sequence Manager. It's ok for me. The second one is the locking issue. I am using the LockManagerRemoteImpl. So I think it is ok. Do you use the ODMG-api implementation? http://db.apache.org/ojb/docu/guides/odmg-guide.html Only this implementation supports pessimistic locking by default. The PB-api http://db.apache.org/ojb/docu/guides/pb-guide.html only supports optimistic locking by default. http://db.apache.org/ojb/docu/guides/lockmanager.html For best performance I would recommend to use optimistic locking (needs a 'version' column in the database table) for all concurrent modified persistence objects. The last point is the cache issue. And this is the subject of this mail. Currently I am using ObjectCacheDefaultImpl. I know it is not suitable for distributed environment. That's why I'd like to use distributed cache. Here you can find a short description how the cache works http://www.mail-archive.com/ojb-user@db.apache.org/msg16075.html My estimation is that in most cases OJB will benefit more from a fast DB/DB-cache/network (in combination with a session cache) than from a distributed cache (except you do a lot of "get object by identity" stuff). I would recommend to run some load tests with/without distributed cache. I have heard about OS Cache but it requires a multicast network. It is not possible in my case. I have heard about JCS too. Has anybody ever used it? Sorry, I don't have experience in this. I don't find information to configure it with OJB. Can anybody help me ? If you use OJB 1.0.5rc1 change the object-cache element within your jdbc-connection-descriptor to one global cache region: a cache region for each class: For version 1.0.4 specifiy the full qualified class name (e.g. org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl). You can configure the JCS cache via the cache.ccf properties file. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugs in 1.0.5rc1
Hi Sascha,
Sascha Broich wrote:
Hi Armin
yep, this is the intended behavior. This method (beside user specific
ManageableCollection implementations) only allow base collection
classes
(List, Set,...).
The mentioned line is similar to:
Set.class.equals(fieldClass)
Okay, if this is intended.
It was just a stumbling block.
I will look if I can change our code with backward compatibility.
Below you can find a new (backward compatible) version of method
CollectionTypes#getCollectionClass. Give it a try.
You are right, this should not happen. In the OJB test-suite we do
several tests using table-per-subclass inheritance and this never
happens.
Could you post the mapping for class A1, A0 and the source of the
query
then I can try to reproduce your issue.
The criteria for this issue was build by using the table column name
'PHB_USRID'.
After I changed this to 'addIsNull("m_iUserId") the query succeeded.
Thanks for the detailed description. Now I'm able to reproduce the bug.
I setup a test using table-per-subclass inheritance. This test search
for a nullified field using a field attribute and then a column attribute:
Criteria c1 = new Criteria()
.addEqualTo("id_2", id_2)
.addIsNull("name");
Criteria c2 = new Criteria()
.addEqualTo("id_2", id_2)
.addColumnIsNull("NAME");
QueryByCriteria q1 = QueryFactory.newQuery(Executive.class, c1, true);
QueryByCriteria q2 = QueryFactory.newQuery(Executive.class, c2, true);
The first query pass, the second returns the same error you described in
a previous mail. Will try to fix this ASAP!
regards,
Armin
new version of method CollectionTypes#getCollectionClass
---
// configurable property
private boolean optimized = true;
public Class getCollectionClass(CollectionDescriptor cds) throws
PersistenceBrokerException
{
Class result = cds.getCollectionClass();
if(result == null)
{
boolean failed = false;
Class fieldType = cds.getPersistentField().getType();
/*
first check for user specific ManageableCollection type,
then check for base collection types (List, Set, Vector,
Collection)
and check if the collection field type is assignable from the
predefined
collection type implementation (predefined/configured
implemenations of ManageableCollection).
*/
if (ManageableCollection.class.isAssignableFrom(fieldType))
{
result = fieldType;
}
else if(Vector.class.isAssignableFrom(fieldType))
{
result = cds.isMtoNRelation() ? getManyToManyVector() :
getOneToManyVector();
if(!fieldType.isAssignableFrom(result))
{
failed = true;
}
}
else if(List.class.isAssignableFrom(fieldType))
{
result = cds.isMtoNRelation() ? getManyToManyList() :
getOneToManyList();
if(!fieldType.isAssignableFrom(result))
{
failed = true;
}
}
else if(Set.class.isAssignableFrom(fieldType))
{
result = cds.isMtoNRelation() ? getManyToManySet() :
getOneToManySet();
if(!fieldType.isAssignableFrom(result))
{
failed = true;
}
}
else if(Collection.class.isAssignableFrom(fieldType))
{
result = cds.isMtoNRelation() ? getManyToManyCollection() :
getOneToManyCollection();
if(!fieldType.isAssignableFrom(result))
{
failed = true;
}
}
else if(fieldType.isArray())
{
result = cds.isMtoNRelation() ? getManyToManyArray() :
getOneToManyArray();
}
else
{
failed = true;
}
if(failed)
{
throw new MetadataException(
"Cannot determine a collection type for
collection/list/set/array field '"
+ cds.getAttributeName() + "' of type '" +
fieldType + "' in persistence capable class '"
+ cds.getClassDescriptor().getClassNameOfObject() +
"'");
}
// performance optimization
if(optimized)
{
cds.setCollectionClass(result);
}
}
return result;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Bugs in 1.0.5rc1
Hi Sascha,
Sascha Broich wrote:
Hi Armin,
The method CollectionTypes#getCollectionClass is correctly
implemented.
First this method checks for user specific collection class
implementations (implementations of ManageableCollection), then this
method try to resolve the collection class implementations for 1:n and
m:n collection-fields (of type Collection, List, Set or array types)
of
persistence capable classes.
The "real bug" is a typo in the OJB.properties file:
replace
CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.Man
ageableSet
with
CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.Man
ageableHashSet
I will fix this ASAP. Thanks again.
I'm sorry, but the change in the OJB.properties file didn't solve the
problem.
I still get the MetadataException "Cannot determine a collection type
for collection/list/set/array field 'devices' of type 'class
java.util.HashSet' in persistence capable class 'Abc'"
As I wrote: HashSet.class.isAssignableFrom(java.util.Set.class) will
ALWAYS fail.
yep, this is the intended behavior. This method (beside user specific
ManageableCollection implementations) only allow base collection classes
(List, Set,...).
The mentioned line is similar to:
Set.class.equals(fieldClass)
Please remember, the method can only be successful in the direction
superclass.isAssignableFrom(subclass).
The only superclass of java.util.Set is java.util.Collection.
So as long as there is a HashSet instead of a Set used as field the
check fails, despite the OJB.properties file.
In 1.0.4 this assignable check was against RemovalAwareSet, which is a
subclass of HashSet.
yep, you are right. But now the collection types are configurable in
OJB.properties file e.g.
CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.ManageableHashSet
So we can't check against an implementation class.
Currently RC1 automatic resolve only base collection types like
Collection, List, Vector and Set.
Two workarounds:
1.) If you change field 'devices' to type 'Set' it should work (with
patched OJB.properties file).
2.) Directly set a collection implementation class in the
collection-descriptor (you can use a shortcut-name for shipped
implementations - see documentation):
I have to admit that the current behavior isn't perfect ;-), so I will
improve class CollectionTypes to be backward compatible with 1.0.4:
First check the collection field base type (e.g. subclass of class Set)
and then make sure that the ManageableCollection implemetation class is
a subclass of the field collection type.
if (ManageableCollection.class.isAssignableFrom(fieldType))
{
result = fieldType;
}
else if(Set.class.isAssignableFrom(fieldType))
{
result = cds.isMtoNRelation() ? getManyToManySet() : getOneToManySet();
if(!fieldType.isAssignableFrom(result))
{
failed = true;
}
}
...
Another bug is in the statement creation when a subclass is
involved.
Note: A0 is the subclass table from A1, PHB_USRID exists only in A1
1.0.4 creates something like
SELECT
A0.PHB_ID ,
A1.PHB_USRID ,
FROM
IPT_PHONEBOOKCSV A0
INNER JOIN IPT_PHONEBOOK A1
ON
A0.PHB_ID = A1.PHB_ID
WHERE
PHB_USRID IS NULL
1.0.5rc1 creates
SELECT
A0.PHB_ID ,
A1.PHB_ID ,
A1.PHB_USRID ,
FROM
IPT_PHONEBOOKCSV A0
INNER JOIN IPT_PHONEBOOK A1
ON
A0.PHB_ID = A1.PHB_ID
WHERE
A0.PHB_USRID IS NULL
The WHERE criteria assignment to A0 the statement produces an
exception
for the nonexisting column A0.PHB_USRID.
Note, that in the SELECT of 1.0.5rc1 is also A1.PHB_ID, which is not
in
the statement of 1.0.4.
If PHB_USRID only exists in A1 then A1 is a subclass of (super) class
A0. In this case it's not allowed to build a query with target class
A0
and fields only existing in A1.
Is this the case? If not, please post some more details (java pseudo
code, class mapping).
class A1
{
PHB_ID;
PHB_USRID;
PHB_NAME;
}
class A0 extends A1
{
PHB_CSV;
}
And the tables are
Table A1
PHB_ID
PHB_USRID
PHB_NAME
Table A0
PHB_ID
PHB_CSV
Because of the inheritance there shouldn't be a need for the column
PHB_USRID in the table for the derived class A0.
The correct statement should be
SELECT
A0.PHB_ID ,
A0.PHB_CSV ,
A1.PHB_USRID,
A1.PHB_NAME
FROM
A0 INNER JOIN A1 ON A0.PHB_ID = A1.PHB_ID
WHERE
A1.PHB_USRID IS NULL
I'm not sure if the 1.0.4 resolved this correct but it didn't add the
alias to the where clause so the database assigned the correct column by
itself.
You are right, this should not happen. In the OJB test-suite we do
several tests using table-per-subclass inheritance and this never happens.
Could you post the mapping for class A1, A0 and the source of the query
then I can try to reproduce your issue.
regards,
Armin
Regards,
Sascha Broich
--
Re: Bugs in 1.0.5rc1
Hi Sascha, thank you very much for testing the RC1! Sascha Broich wrote: Hello, I found a bug in org.apache.ojb.broker.core.CollectionTypes#getCollectionClass(Collection Descriptor). The "isAssignableFrom" check has to be inverted. For instance: HashSet.class.isAssignableFrom(Set.class) yields false and a MetadataException is thrown. Inverted to Set.class.isAssignableFrom(HashSet.class) yields true and the correct branch gets entered. The method CollectionTypes#getCollectionClass is correctly implemented. First this method checks for user specific collection class implementations (implementations of ManageableCollection), then this method try to resolve the collection class implementations for 1:n and m:n collection-fields (of type Collection, List, Set or array types) of persistence capable classes. The "real bug" is a typo in the OJB.properties file: replace CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.ManageableSet with CollectionTypes.OneToManySet=org.apache.ojb.broker.util.collections.ManageableHashSet I will fix this ASAP. Thanks again. Another bug is in the statement creation when a subclass is involved. Note: A0 is the subclass table from A1, PHB_USRID exists only in A1 1.0.4 creates something like SELECT A0.PHB_ID , A1.PHB_USRID , FROM IPT_PHONEBOOKCSV A0 INNER JOIN IPT_PHONEBOOK A1 ON A0.PHB_ID = A1.PHB_ID WHERE PHB_USRID IS NULL 1.0.5rc1 creates SELECT A0.PHB_ID , A1.PHB_ID , A1.PHB_USRID , FROM IPT_PHONEBOOKCSV A0 INNER JOIN IPT_PHONEBOOK A1 ON A0.PHB_ID = A1.PHB_ID WHERE A0.PHB_USRID IS NULL The WHERE criteria assignment to A0 the statement produces an exception for the nonexisting column A0.PHB_USRID. Note, that in the SELECT of 1.0.5rc1 is also A1.PHB_ID, which is not in the statement of 1.0.4. If PHB_USRID only exists in A1 then A1 is a subclass of (super) class A0. In this case it's not allowed to build a query with target class A0 and fields only existing in A1. Is this the case? If not, please post some more details (java pseudo code, class mapping). regards, Armin Regards, Sascha Broich - 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: Is it possible to force OJB not use execute a prepared statement?
Hi Roger, Janssen, Roger wrote: Hi, Just a general question about sql statement execution. Is it possible to force OJB not to execute a prepared statement, but to execute the sql as a regular sql statement? Sorry no! The use of prepared statements is deeply rooted in the OJB core. The reason behind this is that we hit some kind of upperbound limit with MSSQL regarding the maximum allowed number of parameters in a prepared statement. Some of the statements that are being generated by OJB are rejected (SQL exceptions are thrown) by MSSQL, because this upperbound is crossed. Maybe you can find a "hidden property" to adjust the upper bound of maximal PS parameter. regards, Armin One solution would be to not use a prepared statement in these cases. Greetings, Roger Janssen * The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements
Hi Roger,
Janssen, Roger wrote:
Hi Armin,
Just to make it absolutely clear so we talk about the same thing;
When I execute a reportquery, I expect to get records back, and if I get
duplicate records back because of the joins I created, well that is
fine. But when I execute a 'normal' query, and OJB returns instantiated
objects, I would like to get a list without duplicated records.
If this just is not possible, so be it.
You can get duplicate objects back too if the order-by clause contains
fields which are not part of the output columns (class fields). It's a
general behavior of OJB.
For example, if I modify #ensureColumnsOrderBy and specify a order-by
field/column which is not part of the output columns we get:
1.)
SELECT DISTINCT A0.ID_,A0.TITLE_,A0.VERSION_
FROM SAMPLE_BOOK A0
INNER JOIN SAMPLE_REVIEW A1 ON A0.ID_=A1.FK_BOOK
WHERE (A0.ID_ < A1.ID_) AND
A0.TITLE_ LIKE '%_testOrderBy_2_1204304719937_%'
ORDER BY A1.ID_ DESC
This doesn't work with maxDB and oracle (I suppose other DB too). As
workaround OJB always adds the missing columns as "hidden" output
columns. With the unmodified #ensureColumnsOrderBy method OJB will generate:
2.)
SELECT DISTINCT A0.ID_,A0.TITLE_,A0.VERSION_,A1.ID_ as ojb_col_4
FROM SAMPLE_BOOK A0
INNER JOIN SAMPLE_REVIEW A1 ON A0.ID_=A1.FK_BOOK
WHERE (A0.ID_ < A1.ID_) AND
A0.TITLE_ LIKE '%_testOrderBy_2_1204305513406_%'
ORDER BY 4 DESC
I don't know if the order-by clause in the 1. example makes sense, in
the 2. example the returned result set makes sense (with ordered A1.ID_
column and duplicated A0.ID_,A0.TITLE_,A0.VERSION_ columns for each
match) but the result returned by OJB ignore the ojb_col_4 and only
returns A0.ID_,A0.TITLE_,A0.VERSION_.
It is always nice to have something configurable :) ... But adding a new
method to invoke different behaviour on different databases, I don't
know if that's what we all want... I am not eager to write database
dependent code... So if it is not unavoidable to prevent duplicate
records... I can live with that..
If we make it configurable you can choice which behavior of OJB you
prefer (1. doesn't work with all DB, or 2. works for all DB but return
unexpected duplicates).
regards,
Armin
Roger Janssen
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 4:56 PM
To: OJB Users List
Subject: Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses
are not replaced by the generated aliases for the joins resulting in
illegal SQL statements
Hi Roger,
Janssen, Roger wrote:
Hi Armin,
Tested what you described and the ordering seems to work in our setup
as well.
What does not work however is that I get duplicate items returned. For
every match in the right-handside of the 1:N relation, I get the same
object returned. Even if I execute a distinct query.
This behavior is intended by OJB. OJB adds all "unknown fields/columns"
to the query statement. See SqlQueryStatement#ensureColumnsOrderBy.
If you change this method in the same way like #ensureColumnsGroupBy
works, the fields won't be added and you won't get duplicate items.
This works with e.g. mysql but doesn't work for e.g. maxDB, oracle -
they always expect an output column in the order-by clause.
So, I don't know how to solve this issue? Should we make this
configurable e.g. Query.addMissingOrderByColumns(boolean enable)?
Also the setPathOuterJoin functionality does not work. Inner joins
keep being generated. After this latest info from you I tried the same
with the setPathOuterJoin :
query.setPathOuterJoin("myAlias");
And
query.setPathOuterJoin("myAlias.collectionAttr");
But no luck.
ok I will try to setup some tests too.
regards,
Armin
Greetings,
Roger Janssen
iBanx
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 27, 2008 2:51 PM
To: OJB Users List
Subject: Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses
are not replaced by the generated aliases for the joins resulting in
illegal SQL statements
Hi Roger,
I start work on OJB-137 (your issue) and noticed while "playing" with
order-by tests that the following notations seems to work (class Book
has a 1:n relation to class Review):
Criteria c1 = new Criteria()
.addEqualTo("reviews.summary", "3_review" + name);
c1.setAlias("alias_1"); Criteria c2 = new Criteria()
.addEqualTo("reviews.summary", "4_review" + name);
c2.setAlias("alias_2"); c1.addAndCriteria(c2); ReportQueryByCriteria q
= QueryFactory.newReportQuery(Sample.Book.class,
c1, true);
q.setAttributes(new String[]{"id", "title","reviews.id"});
q.addOrderByDescending("alias_2.reviews.id");
If I prefix the path expression w
Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements
Hi Roger,
Janssen, Roger wrote:
Hi Armin,
Tested what you described and the ordering seems to work in our setup as
well.
What does not work however is that I get duplicate items returned. For
every match in the right-handside of the 1:N relation, I get the same
object returned. Even if I execute a distinct query.
This behavior is intended by OJB. OJB adds all "unknown fields/columns"
to the query statement. See SqlQueryStatement#ensureColumnsOrderBy.
If you change this method in the same way like #ensureColumnsGroupBy
works, the fields won't be added and you won't get duplicate items.
This works with e.g. mysql but doesn't work for e.g. maxDB, oracle -
they always expect an output column in the order-by clause.
So, I don't know how to solve this issue? Should we make this
configurable e.g. Query.addMissingOrderByColumns(boolean enable)?
Also the setPathOuterJoin functionality does not work. Inner joins keep
being generated. After this latest info from you I tried the same with
the setPathOuterJoin :
query.setPathOuterJoin("myAlias");
And
query.setPathOuterJoin("myAlias.collectionAttr");
But no luck.
ok I will try to setup some tests too.
regards,
Armin
Greetings,
Roger Janssen
iBanx
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 27, 2008 2:51 PM
To: OJB Users List
Subject: Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses
are not replaced by the generated aliases for the joins resulting in
illegal SQL statements
Hi Roger,
I start work on OJB-137 (your issue) and noticed while "playing" with
order-by tests that the following notations seems to work (class Book
has a 1:n relation to class Review):
Criteria c1 = new Criteria()
.addEqualTo("reviews.summary", "3_review" + name);
c1.setAlias("alias_1"); Criteria c2 = new Criteria()
.addEqualTo("reviews.summary", "4_review" + name);
c2.setAlias("alias_2"); c1.addAndCriteria(c2); ReportQueryByCriteria q =
QueryFactory.newReportQuery(Sample.Book.class,
c1, true);
q.setAttributes(new String[]{"id", "title","reviews.id"});
q.addOrderByDescending("alias_2.reviews.id");
If I prefix the path expression with the user alias it seems to work
("alias_2.reviews.id" instead of "alias_2.id"). Did you tried this too?
regards,
Armin
Armin Waibel wrote:
Hi Roger,
I create two new "user-alias" related bug reports:
http://issues.apache.org/jira/browse/OJB-137
https://issues.apache.org/jira/browse/OJB-139
OJB-137 reflects your issue. Locally I fixed OJB-139 (easier to fix
then
137) and start work on OJB-137 (seems more complex to fix).
regards,
Armin
Armin Waibel wrote:
Hi Roger,
now I get your point (I'm a bit slow on the uptake ;-)). I start
writing many new "order by" tests to isolate the problem and to make
sure that changes don't have unrequested side-effects.
> itself was not stable enough for us). In fact, I helped
implementing > this feature in OJB a long time ago, and I believe
the documentation > on > the OJB site is the documentation I once
sent to you guys.
You are right, I found your example in the query documentation. But I
can't find a test in the OJB test-suite. I think this is the reason
why this feature got lost between 1.0.rc6 and now (the criteria/query
stuff was reworked/improved since 1.0rc6).
My new tests show another bug when using a user alias on a 1:n
relation with table-per-subclass inheritance - but this is another
story. After finish test writing, I will do my best to find a patch
for your problem and keep you up-to-date.
regards,
Armin
Janssen, Roger wrote:
Hi,
The management summary answer to your question "is it important to
support alias-names in order by and having clause" is : Yes, it is
really really really important!!!
So now for some background information explaining our situation.
We implemented a concept to support non-modelled (abstract)
attributes.
We need to support many different complex forms and datasets for our
customers. The deviation between customers is huge, so modifying our
domain model (and thus our pojos and thus out database tables) for
every customer implementation is not an option. We need to have a
stable core domain model.
So all our objects in our domain model have a collection property
that is capable of holding a collection of abstract-attribute
instances, it's a standard 1:N relation which OJB supports. Abstract
attribute classes are classes implementing name-value tuples, the
name of the attribute, and the value of the attribute. So adding new
attributes to specific objectclass instances implies we just have to
add abstract attribute instances to the collection and OJB will
Re: case insensitive LIKE and addLike vs addSQL
Hi Thomas, Geike, Thomas wrote: Hi all, I am having trouble to generate case insensitive LIKE sql clauses with ojb. The SQL I want to produce in the end should look something like this: SELECT * FROM WHERE UPPER() LIKE UPPER(); Does anyone know a solution to this problem? Any help appreciated. Thanks a lot in advance. Sorry no. Currently OJB doesn't analyze query parameter values (e.g. "LIKE UPPER()") for sql-functions. By the way, is it allowed to use function expressions as parameter value in a PreparedStatement? regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements
Hi Roger,
I start work on OJB-137 (your issue) and noticed while "playing" with
order-by tests that the following notations seems to work (class Book
has a 1:n relation to class Review):
Criteria c1 = new Criteria()
.addEqualTo("reviews.summary", "3_review" + name);
c1.setAlias("alias_1");
Criteria c2 = new Criteria()
.addEqualTo("reviews.summary", "4_review" + name);
c2.setAlias("alias_2");
c1.addAndCriteria(c2);
ReportQueryByCriteria q = QueryFactory.newReportQuery(Sample.Book.class,
c1, true);
q.setAttributes(new String[]{"id", "title","reviews.id"});
q.addOrderByDescending("alias_2.reviews.id");
If I prefix the path expression with the user alias it seems to work
("alias_2.reviews.id" instead of "alias_2.id"). Did you tried this too?
regards,
Armin
Armin Waibel wrote:
Hi Roger,
I create two new "user-alias" related bug reports:
http://issues.apache.org/jira/browse/OJB-137
https://issues.apache.org/jira/browse/OJB-139
OJB-137 reflects your issue. Locally I fixed OJB-139 (easier to fix then
137) and start work on OJB-137 (seems more complex to fix).
regards,
Armin
Armin Waibel wrote:
Hi Roger,
now I get your point (I'm a bit slow on the uptake ;-)). I start
writing many new "order by" tests to isolate the problem and to make
sure that changes don't have unrequested side-effects.
> itself was not stable enough for us). In fact, I helped implementing
> this feature in OJB a long time ago, and I believe the documentation
> on
> the OJB site is the documentation I once sent to you guys.
You are right, I found your example in the query documentation. But I
can't find a test in the OJB test-suite. I think this is the reason
why this feature got lost between 1.0.rc6 and now (the criteria/query
stuff was reworked/improved since 1.0rc6).
My new tests show another bug when using a user alias on a 1:n
relation with table-per-subclass inheritance - but this is another
story. After finish test writing, I will do my best to find a patch
for your problem
and keep you up-to-date.
regards,
Armin
Janssen, Roger wrote:
Hi,
The management summary answer to your question "is it important to
support alias-names in order by and having clause" is : Yes, it is
really really really important!!!
So now for some background information explaining our situation.
We implemented a concept to support non-modelled (abstract) attributes.
We need to support many different complex forms and datasets for our
customers. The deviation between customers is huge, so modifying our
domain model (and thus our pojos and thus out database tables) for every
customer implementation is not an option. We need to have a stable core
domain model.
So all our objects in our domain model have a collection property that
is capable of holding a collection of abstract-attribute instances, it's
a standard 1:N relation which OJB supports. Abstract attribute classes
are classes implementing name-value tuples, the name of the attribute,
and the value of the attribute. So adding new attributes to specific
objectclass instances implies we just have to add abstract attribute
instances to the collection and OJB will store them in the apropriate
table in the database. We do not have to modify our domain model by
adding new java properties to the affected classes and adding new
columns to the affected tables.
So querying for values of object properties, represented by abstract
attributes, we need to create clauses combining the name/value
properties of the abstract attribute instances.
So an example query with two selection criteria based on abstract
attributes of an object could be:
SELECT * FROM PERMIT AS A0 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A1
INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A2
WHERE A0.ID=A1.ID AND A0.ID=A2.ID AND
(A1.NAME=' AND A1.VALUE='') AND
(A2.NAME=' AND A2.VALUE='');
Since we need to work with bounded name/value pairs, we need to bind
them together using a alias, in this example the aliases are A1 and A2.
So if we want to order the resultset on such an abstract attribute value
the query would look like:
SELECT * FROM PERMIT AS A0 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A1
INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A2
WHERE A0.ID=A1.ID AND A0.ID=A2.ID AND
(A1.NAME=' AND A1.VALUE='') AND
(A2.NAME=' AND A2.VALUE='')
ORDER BY A2.VALUE;
We need to use the alias to link the orderby to the proper join, of
which there are two, to the same join table (the abstract attribute
table)!
This is rather common functionality, currently supported in all our
applications, supported by OJB 1.0rc6 that we use (the 1.0 release
itself was not stable enough for us). In fact, I helped implementing
this feature in OJB a long time ago,
Re: Isolation level
Hi Christian,
Christian Lipp wrote:
Hi Armin,
thank you for quick answer and sorry for my long delay.
We are using an older OJB version (1.0.1.x), so I thought I cannot use your
recommendation and wanted to perform a backport now.
I got the actual OJB now and examined it, but also couldn't find an
attribute in the jdbc-connection-descriptor (I checked the repository.dtd).
So I asume I have to implement the JDBC transaction level as attribute for
jdbc-connection-descriptor into OJB or do I miss something?
Some databases support transaction-isolation settings by append a
property in the database URL - e.g. maxDB:
dbalias="//localhost/ojb?isolation=TRANSACTION_READ_COMMITTED
Additionally you can specify connection/database properties as custom
attributes with prefix "jdbc.".
OJB will set these properties (with jdbc.* prefix) when create the
connection:
Connection con = DriverManager.getConnection(url, properties);
Could someone point me in the right direction for this implementation? I
assume I have to read the attribute and apply it in the function
PlatformDefaultImpl.initializeJdbcConnection.
If your database doesn't support isolation setting shown above, you can
indeed extend a existing Platform class and override
#initializeJdbcConnection. Within this method you can easily get custom
attributes using:
class PlatformMyOwnImpl extends PlatformMySQLImpl{
...
public void initializeJdbcConnection(Connection conn)
{
String isolation = jcd.getAttribute("isolation", null);
...
}
}
All shown solutions will work with latest OJB source
http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html
I don't check the older versions.
regards,
Armin
Thanks in advance, CL
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Freitag, 25. Jänner 2008 03:03
To: OJB Users List
Subject: Re: Isolation level
Hi Christian,
Christian Lipp wrote:
I am still looking for an solution for my lock level settings and
therefore I am digging through the OJB source.
What I am not sure at the moment is if the setting of the
isolation-level is generally ignored in OJB?
I couldn't find the place in the OJB code where the isolation level is
set to the DescriptorRepository and later to the connection.
In my optionion the isolation-level in the XML file is ignored.
Could someone point me in the right direction?
Out of the box the isolation-level setting is only used by the ODMG-api
which use pessimistic locking by default.
http://db.apache.org/ojb/docu/guides/lockmanager.html#Pessimistic-Locking
The PB-api doesn't use pessimistic locking, thus it will ignore these
settings.
The database transaction levels are completely independent from the
isolation-level setting in OJB. So you can use different database
transaction levels (e.g. as property in the dbalias attribute in the
jdbc-connection-descriptor)
regards,
Armin
Thanks in advance,
CL
-
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: Mapping a List (or Set) with OJB.
Hi Johan,
Johan Andersson wrote:
Greetings!
Say I have a class MyClass it looks like this:
public class MyClass {
private int id;
private String name; private List myIntegers = new
ArrayList;
/* getters and setters omitted ... */
}
What options do I have if I want to persist this class using OJB?
The List is causing me problems since it is not a pesistent
entity class.
Requirements impede me from just putting it into one field and use a
IntList2VarcharFieldConversion.
Requrements want me to have the List data in a separate
database table.
But I just cant figure out how to map this.
Sorry, to have the List data in a separate database table is
not supported by OJB. In this case OJB expect a persistence capable
class e.g. Items.
regards,
Armin
Here's my tables (I am using MySQL):
CREATE TABLE `MY_CLASS` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `ITEMS` (
`my_class_id` int(10) unsigned NOT NULL,
`item_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`my_class_id`, `item_id`)
);
Thankful for any suggestions.
/JOHAN
-
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: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements
Hi Roger, I create two new "user-alias" related bug reports: http://issues.apache.org/jira/browse/OJB-137 https://issues.apache.org/jira/browse/OJB-139 OJB-137 reflects your issue. Locally I fixed OJB-139 (easier to fix then 137) and start work on OJB-137 (seems more complex to fix). regards, Armin Armin Waibel wrote: Hi Roger, now I get your point (I'm a bit slow on the uptake ;-)). I start writing many new "order by" tests to isolate the problem and to make sure that changes don't have unrequested side-effects. > itself was not stable enough for us). In fact, I helped implementing > this feature in OJB a long time ago, and I believe the documentation > on > the OJB site is the documentation I once sent to you guys. You are right, I found your example in the query documentation. But I can't find a test in the OJB test-suite. I think this is the reason why this feature got lost between 1.0.rc6 and now (the criteria/query stuff was reworked/improved since 1.0rc6). My new tests show another bug when using a user alias on a 1:n relation with table-per-subclass inheritance - but this is another story. After finish test writing, I will do my best to find a patch for your problem and keep you up-to-date. regards, Armin Janssen, Roger wrote: Hi, The management summary answer to your question "is it important to support alias-names in order by and having clause" is : Yes, it is really really really important!!! So now for some background information explaining our situation. We implemented a concept to support non-modelled (abstract) attributes. We need to support many different complex forms and datasets for our customers. The deviation between customers is huge, so modifying our domain model (and thus our pojos and thus out database tables) for every customer implementation is not an option. We need to have a stable core domain model. So all our objects in our domain model have a collection property that is capable of holding a collection of abstract-attribute instances, it's a standard 1:N relation which OJB supports. Abstract attribute classes are classes implementing name-value tuples, the name of the attribute, and the value of the attribute. So adding new attributes to specific objectclass instances implies we just have to add abstract attribute instances to the collection and OJB will store them in the apropriate table in the database. We do not have to modify our domain model by adding new java properties to the affected classes and adding new columns to the affected tables. So querying for values of object properties, represented by abstract attributes, we need to create clauses combining the name/value properties of the abstract attribute instances. So an example query with two selection criteria based on abstract attributes of an object could be: SELECT * FROM PERMIT AS A0 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A1 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A2 WHERE A0.ID=A1.ID AND A0.ID=A2.ID AND (A1.NAME=' AND A1.VALUE='') AND (A2.NAME=' AND A2.VALUE=''); Since we need to work with bounded name/value pairs, we need to bind them together using a alias, in this example the aliases are A1 and A2. So if we want to order the resultset on such an abstract attribute value the query would look like: SELECT * FROM PERMIT AS A0 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A1 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A2 WHERE A0.ID=A1.ID AND A0.ID=A2.ID AND (A1.NAME=' AND A1.VALUE='') AND (A2.NAME=' AND A2.VALUE='') ORDER BY A2.VALUE; We need to use the alias to link the orderby to the proper join, of which there are two, to the same join table (the abstract attribute table)! This is rather common functionality, currently supported in all our applications, supported by OJB 1.0rc6 that we use (the 1.0 release itself was not stable enough for us). In fact, I helped implementing this feature in OJB a long time ago, and I believe the documentation on the OJB site is the documentation I once sent to you guys. The upcoming 1.0.5 release has some features that we have been waiting for, for several years. We have been able to postpone improvements in our applications for this long, but we cannot do this any longer. So we really need these new features 1.0.5 implements, but we need the user-alias in the orderby to work as well, otherwise we will loose a lot of functionality and our customers will not accept that. Some of the required features are the native limit-clause implementations, the reference descriptor implementation without using foreign-keys (I requested this feature for more then a year ago myself), etc., etc.. I hope you now have an understanding of how we use this feature, and that we cannot afford to loose it. Greetings, Roger Janssen iBanx * The info
Re: How to check for null values when using proxies?
Armin Waibel wrote: In the 1:n associations I set auto-retrieve="false" and proxy="dynamic". As my classes do not implement interfaces, I'm using CGLib as ProxyFactoryClass. Now I get your point. You are using dynamic proxies for the referenced objects (and maybe a proxy reference for the 1:n relation too) and OJB return the wrong instance for all subclasses. Another problem that came up after I started using proxies is in the hierarchy mapping. I'm using just one table to map my class hierarchy. So, this table has a CLASSNAME field to identify which class to load. In the constructor of my base class I have a setOjbConcreteClass(this.getClass().getName()) call. Before using proxies, the class name was configured correctly. But after, instead of having the real object class name, the application configures the classname field using the proxy class name. I assume there should be something wrong with my mapping files or some other point in my application. As said earlier, I believe proxies should be transparent. Did someone here experience the same problems? Hm, I will have a look at this tomorrow (will try to reproduce your issue). I can reproduce the issue and create a bug report: http://issues.apache.org/jira/browse/OJB-138 Setup some new tests and it seems that I can fix it soon. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to check for null values when using proxies?
Hi,
Schmidt wrote:
Hi again Armin,
I saw some discussions regarding the AbstractIndirectionHandler class, maybe
the method "public Object invoke" is outdated in the OJB version in use by
me. I'm using OJB1.0.4 and the jar file date is 31/12/2005. Is that correct?
yep!
Is there any other version available? If so, please point me out where can I
get it.
Thank you!
You can test the upcoming 1.0.5 version. The 1.0.5rc1 is stable but
contain some specific query bugs. Details see this thread:
http://www.mail-archive.com/ojb-user%40db.apache.org/msg16078.html
regards,
Armin
Schmidt wrote:
Hi Armin,
Thank you for the answer.
I'm using the 1.0.4 version. And the same problem happens with 1:n
associations as well. In the 1:n associations I set auto-retrieve="false"
and proxy="dynamic". As my classes do not implement interfaces, I'm using
CGLib as ProxyFactoryClass.
I debugged the source code and verified that the collection representing
the n side of the 1:n association is filled with proxy references. That's
good because the real object are not materialized, but when I check for
nullity, the result is false due to proxy references. The solution (ugly)
to bypass this problem is in the ProxyHelper.getRealObject method. But
this solution is invasive, proxies should be transparent.
Another problem that came up after I started using proxies is in the
hierarchy mapping. I'm using just one table to map my class hierarchy. So,
this table has a CLASSNAME field to identify which class to load. In the
constructor of my base class I have a
setOjbConcreteClass(this.getClass().getName()) call. Before using proxies,
the class name was configured correctly. But after, instead of having the
real object class name, the application configures the classname field
using the proxy class name.
I assume there should be something wrong with my mapping files or some
other point in my application. As said earlier, I believe proxies should
be transparent. Did someone here experience the same problems?
Thank you again!
Armin Waibel wrote:
Hi,
Schmidt wrote:
Hi,
Consider that an object A has an association with an object B. Also that
dynamic proxies are in use so that when object A is loaded, a proxy to B
is
created and the object B itself is not materialized. Sometimes, before
taking an action, I need to verify if there is a B object associated to
A.
This check is done as follows:
if (a.getB() == null) {...}
The problem is that even if there isn't a B associated with A, OJB
returns
false because there is always a proxy between A and B. The check is
actually
done using the proxy reference which is always present.
How can we handle that?
Which version of OJB do you use? I try to reproduce this with the
current source (OJB_1_0_RELEASE branch) without success. If class
Article has a 1:1 relation to ProductGroup and I search for an Article
without a ProductGroup I get:
Criteria c = new Criteria().addEqualTo("articleName", name + "without
PG");
q = QueryFactory.newQuery(ArticleWithReferenceProxy.class, c);
Article br = (ArticleWithReferenceProxy) broker.getObjectByQuery(q);
assertNotNull(br);
assertNull(br.getProductGroup());
Could it be that the association between A and B is a 1:n relation?
regards,
Armin
Thank in advance!
-
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: How to check for null values when using proxies?
Hi,
Schmidt wrote:
Hi Armin,
Thank you for the answer.
I'm using the 1.0.4 version. And the same problem happens with 1:n
associations as well.
If you use lazy loading with 1:n or m:n relation OJB always create a
collection proxy object (this helps to avoid a DB query on object
materialization). Recommended way to check n-side existence is to use
Collection.size() method. In this case OJB performs a count-query to
verify the number of the n-side objects.
In the 1:n associations I set auto-retrieve="false"
and proxy="dynamic". As my classes do not implement interfaces, I'm using
CGLib as ProxyFactoryClass.
The setting proxy="dynamic" is an illegal attribute value for reference-
and collection-descriptors (only true/false is valid). It doesn't make
sense (please correct me if am wrong) to use auto-retrieve="false"
(prevent materialization of the 1:n or m:n relation)
http://db.apache.org/ojb/docu/guides/basic-technique.html#Setting+Load%2C+Update%2C+and+Delete+Cascading
in combination with proxy="true" (lazy-loading).
I debugged the source code and verified that the collection representing the
n side of the 1:n association is filled with proxy references. That's good
because the real object are not materialized, but when I check for nullity,
the result is false due to proxy references. The solution (ugly) to bypass
this problem is in the ProxyHelper.getRealObject method. But this solution
is invasive, proxies should be transparent.
Please use Collection.size()
Another problem that came up after I started using proxies is in the
hierarchy mapping. I'm using just one table to map my class hierarchy. So,
this table has a CLASSNAME field to identify which class to load. In the
constructor of my base class I have a
setOjbConcreteClass(this.getClass().getName()) call. Before using proxies,
the class name was configured correctly. But after, instead of having the
real object class name, the application configures the classname field using
the proxy class name.
I assume there should be something wrong with my mapping files or some other
point in my application. As said earlier, I believe proxies should be
transparent. Did someone here experience the same problems?
Hm, I will have a look at this tomorrow (will try to reproduce your issue).
regards,
Armin
Thank you again!
Armin Waibel wrote:
Hi,
Schmidt wrote:
Hi,
Consider that an object A has an association with an object B. Also that
dynamic proxies are in use so that when object A is loaded, a proxy to B
is
created and the object B itself is not materialized. Sometimes, before
taking an action, I need to verify if there is a B object associated to
A.
This check is done as follows:
if (a.getB() == null) {...}
The problem is that even if there isn't a B associated with A, OJB
returns
false because there is always a proxy between A and B. The check is
actually
done using the proxy reference which is always present.
How can we handle that?
Which version of OJB do you use? I try to reproduce this with the
current source (OJB_1_0_RELEASE branch) without success. If class
Article has a 1:1 relation to ProductGroup and I search for an Article
without a ProductGroup I get:
Criteria c = new Criteria().addEqualTo("articleName", name + "without
PG");
q = QueryFactory.newQuery(ArticleWithReferenceProxy.class, c);
Article br = (ArticleWithReferenceProxy) broker.getObjectByQuery(q);
assertNotNull(br);
assertNull(br.getProductGroup());
Could it be that the association between A and B is a 1:n relation?
regards,
Armin
Thank in advance!
-
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: How to check for null values when using proxies?
Hi,
Schmidt wrote:
Hi,
Consider that an object A has an association with an object B. Also that
dynamic proxies are in use so that when object A is loaded, a proxy to B is
created and the object B itself is not materialized. Sometimes, before
taking an action, I need to verify if there is a B object associated to A.
This check is done as follows:
if (a.getB() == null) {...}
The problem is that even if there isn't a B associated with A, OJB returns
false because there is always a proxy between A and B. The check is actually
done using the proxy reference which is always present.
How can we handle that?
Which version of OJB do you use? I try to reproduce this with the
current source (OJB_1_0_RELEASE branch) without success. If class
Article has a 1:1 relation to ProductGroup and I search for an Article
without a ProductGroup I get:
Criteria c = new Criteria().addEqualTo("articleName", name + "without PG");
q = QueryFactory.newQuery(ArticleWithReferenceProxy.class, c);
Article br = (ArticleWithReferenceProxy) broker.getObjectByQuery(q);
assertNotNull(br);
assertNull(br.getProductGroup());
Could it be that the association between A and B is a 1:n relation?
regards,
Armin
Thank in advance!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping hierarchy in one table problem
Schmidt wrote: Upgraded to 1.0.4 and the problem persists. Any idea? In OJB test-suite we run several tests using table per hierarchy inheritance without any problems. So please, post all information to reproduce your issue - java source code or pseudo code of the java objects and the query. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping hierarchy in one table problem
Hi,
which version of OJB do you use?
Schmidt wrote:
Hi,
I'm facing a hard time trying to fix a problem in my app. Consider the
floowing class hierarchy:
class Project {..}
class ChildProject extends Project {..}
class GrandChildProject extends ChildProject {..}
How do you set the ojbConcreteClass attribute in your java object?
All these classes are mapped to the same table: PROJECT_TABLE
Here are the mappings:
...some fields here...
...some fields here...
...some fields here...
Somehow when I search for GrandChildProject objects, OJB returns a
ChildProject reference. This ends up in a ClassCastException. Is there
anything wrong in the mappings or strategy used in this example?
The mapping seems ok.
regards,
Armin
Thanks in advance!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimizing object materialization for 1:N relations
Hi Tino, Tino Schöllhorn wrote: Hi, we are using OJB-1.0.1 and evertything works fine. Now I have the following situation: We have a security-mechanism which uses the classes ACL (AccessControlList) and ACLEntry. One ACL has many ACLEntries. Now when using the standard OJB-Materialization methods OJB uses 2 SQLs to materialize on ACL. One for the ACL and one for the ACLEntry. Because we have MANY of those ACLs I am curious if it is possible to overwrite the materialization-method so that just one SQL is used. I thought about using "Prefeteched Relationships" but I noticed that there are also 2 SQLs. The "Prefeteched Relationships" is useful if you search for more than one ACL, then OJB is able to reduce the queries to read the ACLEntries: http://db.apache.org/ojb/docu/guides/query.html#prefetched+relationships The upcoming version 1.0.5 use "Prefeteched Relationships" for all 1:n relations. Any ideas or even example how I could achieve that? Sorry no. regards, Armin Kind regards Tino - 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: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements
Hi Roger, now I get your point (I'm a bit slow on the uptake ;-)). I start writing many new "order by" tests to isolate the problem and to make sure that changes don't have unrequested side-effects. > itself was not stable enough for us). In fact, I helped implementing > this feature in OJB a long time ago, and I believe the documentation > on > the OJB site is the documentation I once sent to you guys. You are right, I found your example in the query documentation. But I can't find a test in the OJB test-suite. I think this is the reason why this feature got lost between 1.0.rc6 and now (the criteria/query stuff was reworked/improved since 1.0rc6). My new tests show another bug when using a user alias on a 1:n relation with table-per-subclass inheritance - but this is another story. After finish test writing, I will do my best to find a patch for your problem and keep you up-to-date. regards, Armin Janssen, Roger wrote: Hi, The management summary answer to your question "is it important to support alias-names in order by and having clause" is : Yes, it is really really really important!!! So now for some background information explaining our situation. We implemented a concept to support non-modelled (abstract) attributes. We need to support many different complex forms and datasets for our customers. The deviation between customers is huge, so modifying our domain model (and thus our pojos and thus out database tables) for every customer implementation is not an option. We need to have a stable core domain model. So all our objects in our domain model have a collection property that is capable of holding a collection of abstract-attribute instances, it's a standard 1:N relation which OJB supports. Abstract attribute classes are classes implementing name-value tuples, the name of the attribute, and the value of the attribute. So adding new attributes to specific objectclass instances implies we just have to add abstract attribute instances to the collection and OJB will store them in the apropriate table in the database. We do not have to modify our domain model by adding new java properties to the affected classes and adding new columns to the affected tables. So querying for values of object properties, represented by abstract attributes, we need to create clauses combining the name/value properties of the abstract attribute instances. So an example query with two selection criteria based on abstract attributes of an object could be: SELECT * FROM PERMIT AS A0 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A1 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A2 WHERE A0.ID=A1.ID AND A0.ID=A2.ID AND (A1.NAME=' AND A1.VALUE='') AND (A2.NAME=' AND A2.VALUE=''); Since we need to work with bounded name/value pairs, we need to bind them together using a alias, in this example the aliases are A1 and A2. So if we want to order the resultset on such an abstract attribute value the query would look like: SELECT * FROM PERMIT AS A0 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A1 INNER JOIN PERMIT_ABSTRACT_ATTRIBUTE AS A2 WHERE A0.ID=A1.ID AND A0.ID=A2.ID AND (A1.NAME=' AND A1.VALUE='') AND (A2.NAME=' AND A2.VALUE='') ORDER BY A2.VALUE; We need to use the alias to link the orderby to the proper join, of which there are two, to the same join table (the abstract attribute table)! This is rather common functionality, currently supported in all our applications, supported by OJB 1.0rc6 that we use (the 1.0 release itself was not stable enough for us). In fact, I helped implementing this feature in OJB a long time ago, and I believe the documentation on the OJB site is the documentation I once sent to you guys. The upcoming 1.0.5 release has some features that we have been waiting for, for several years. We have been able to postpone improvements in our applications for this long, but we cannot do this any longer. So we really need these new features 1.0.5 implements, but we need the user-alias in the orderby to work as well, otherwise we will loose a lot of functionality and our customers will not accept that. Some of the required features are the native limit-clause implementations, the reference descriptor implementation without using foreign-keys (I requested this feature for more then a year ago myself), etc., etc.. I hope you now have an understanding of how we use this feature, and that we cannot afford to loose it. Greetings, Roger Janssen iBanx * The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended
Re: order by clause in collection-descriptor
Hi Guillaume, Guillaume DROUIN wrote: Hi, Is collection-descriptor can works with 3 fields in the order by clause? Yep, if you use the element: http://db.apache.org/ojb/docu/guides/repository.html#order-by I don't know when we introduced this element, so please check the repository.dtd of your 1.0rc6 version for this element. regards, Armin I apologise for my English. Thank you all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB 1.0.5 release candidate 1 (unofficial)
Hi Reynaldo, Reynaldo Porras García wrote: Hello Armin, I just want to report that I tested OJB_1_0_RELEASE rev 616989 on an application which uses PostgreSQL 8.2.6 and PB implementation. It ran more than 106 junit test and they all passed. Good news! Thanks for this positive feedback. regards, Armin The application enviroment is: -Linux Fedora 8.0 -Java 1.6.0_04 -JDBC version 8.2-506.jdbc3 Greetings, Reynaldo Porras García Hi all, I have uploaded a first (unofficial) release candidate of the upcoming OJB 1.0.5 version. The source distribution can be found here: http://people.apache.org/~arminw/ Please give it a go and report any bugs. The source distribution contains a compiled OJB jar and the full html-documentation (of the upcoming 1.0.5). Further information can be found in the readme and release-notes files (recommended to read both files). If there are no bugs, I think 1.0.5 can be released within the next two or three weeks. regards, Armin - 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: how to re-read repository.xml file without restarting software?
Hi Joose, Joose Vettenranta wrote: Hi, How to re-read repository.xml file without restarting software? This would nice to have when developing software. This is not intended. Anyway it could be possible when using object metadata profiles - but I never tried this. Start OJB with an repository.xml file that contains only a connection-descriptor. Separate the object metadata in another repository file. Then load the object metadata at runtime and add it as metadata profile: http://db.apache.org/ojb/docu/guides/metadata.html#Object+metadata+profiles If you change the object metadata file, remove the profile and re-read the metadata and store with the same profile name. regards, Armin Thanks, Joose - 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: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements
Hi Roger,
Janssen, Roger wrote:
Hi,
When you have two object classes, Permit and AbstractAttribute and
Permit holds a collection of AbstractAttributes (using a collection
descriptor for the abstractattribute collection on the Permit in the
mapping file), we can create a query like below:
Criteria crit1 = new
Criteria().addEqualTo("allAbstractAttributes.name", "aaTest");
UserAlias ua = new UserAlias("myAlias");
crit1.setAlias(ua);
Criteria crit2 = new
Criteria().addLike("allAbstractAttributes.value", "*");
crit2.setAlias(ua);
crit1.addAndCriteria(crit2);
QueryByCriteria query = QueryFactory.newQuery(Permit.class,
crit1, true);
query.addOrderBy("myAlias.value", true);
Collection c = pb.getCollectionByQuery(query);
You are right, this doesn't work with 1.0.5rc1 (with 1.0.4 it doesn't
work too). Is this the correct code? AFAIK this query work without an
alias (my local test show the same generated sql with and without alias):
Criteria crit1 = new Criteria().addEqualTo("allAbstractAttributes.name",
"aaTest");
Criteria crit2 = new Criteria().addLike("allAbstractAttributes.value",
"*").addAndCriteria(crit2);
QueryByCriteria query = QueryFactory.newQuery(Permit.class,crit1, true);
query.addOrderBy("allAbstractAttributes.value", true);
I setup some new query tests with order by clause but I can't think out
a useful test using an alias in the order by clause. Fixing this "bug"
won't be easy (you already notice that ;-)), so I want be sure that it
is important to support alias-names in oder by and having clause.
regards,
Armin
In this query I use a useralias to reference a specific join in my
orderby clause. However the generated SQL looks something like:
SELECT FROM PERMIT A0 INNER JOIN ABSTRACTATTRIBUTE A1
WHERE A0.ID == A1.OID AND A1.NAME = ? AND A1.VALUE LIKE '%'
ORDER BY myAlias.value
So we observe that the defined useralias on the join is not processed
within the orderby clause, and I get a wrong SQL statement throwing an
SQL exception. I would have expected a query like:
SELECT FROM PERMIT A0 INNER JOIN ABSTRACTATTRIBUTE A1
WHERE A0.ID == A1.OID AND A1.NAME = ? AND A1.VALUE LIKE '%'
ORDER BY A1.VALUE
Again, I did some OJB code hacking. I came up with a patch, but I
have the feeling it might be done better/smarter/more efficient and
maybe even implemented in some other location in the code But the
SQL generation code was not quite that transparent regarding this
aspect, so just analyse my patch and see what you do with it.
In the class SqlSelectStatement, in the method protected String
buildSqlString(), there is the following code:
...
...
groupByFields = query.getGroupBy();
ensureColumnsGroupBy(groupByFields, columnList);
orderByFields = query.getOrderBy();
columnList = ensureColumnsOrderBy(orderByFields, columnList, stmt);
...
...
In here the groupByFields and the orderByFields contain the lists of
attributes like the user specified them, so with the useraliases. These
need to be replaced with the generated alias before the
ensurecolumn-methods are called. So I implemented a method
replaceUserAlias doing exactly that and I call this method before the
call to the ensurecolumns-methods.
The code then becomes:
...
...
groupByFields = query.getGroupBy();
// start - iBanx patch
replaceUserAlias(groupByFields, whereCrit);
// end - iBanx patch
ensureColumnsGroupBy(groupByFields, columnList);
orderByFields = query.getOrderBy();
// start - iBanx patch
replaceUserAlias(orderByFields, whereCrit);
// end - iBanx patch
columnList = ensureColumnsOrderBy(orderByFields, columnList, stmt);
...
...
The method implementation is:
// start - iBanx patch
/**
* Replaces any useralias reference in the fieldlist with the
corresponding generated alias of the join releated to the
* whereCrit clause.
*
* @param fields
* @param whereCrit
*/
private void replaceUserAlias(List fields, Criteria whereCrit)
{
// defensive programming preventing NPE's
if((getRoot()!=null) && (whereCrit!=null) &&
(whereCrit.getUserAlias()!=null) && (fields!=null))
{
// continue when we have a join
// -- test it like this because the iterateJoins() method
throes NPE when joins equals null
if(getRoot().joins != null)
{
// iterate over all the joins to check for useraliases
Iterator theJoins = getRoot().iterateJoins();
if(theJoins!=null)
{
while(theJoins.hasNext())
{
Join j = (Join)theJoins.next();
if(j.right!=null)
{
Re: BUGREPORT (more info availabe) : OJB 1.0.5 - count query in combination with IN-clause
Hi Roger, I checked in your bug fix to SVN. The OJB test-suite pass without failures (including two new count query tests relating to this bug). regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUGREPORT (more info availabe) : OJB 1.0.5 - count query in combination with IN-clause
Hi Roger,
Janssen, Roger wrote:
Hi,
Been debugging some OJB code
In class PersistenceBrokerImpl, in method OJBIterator
getRsIteratorFromQuery(Query query, ClassDescriptor cld,
RsIteratorFactory factory), in there this call is made:
query.preprocess(this);
However, the earlier classcastexception bug, learned us that we may have
enclosing queries as well, and the actual query is embedded in the
enclosing query. Looking at the EnclosingReportQuery class, we observe
that it does not implement the proper preprocess method that
preprocesses the embedded query. So we need to add that method to the
EnclosingReportQuery class (something like) :
/**
* @see
org.apache.ojb.broker.query.Query#preprocess(org.apache.ojb.broker.Persi
stenceBrokerInternal)
*/
public void preprocess(PersistenceBrokerInternal aPb)
{
// is this required???
super.preprocess(aPb);
// this one is
query.preprocess(aPb);
}
This way, calling the preprocess in the PersistenceBrokerImpl and in the
JdbcAccessImpl classes is covered for the EnclosingReportQuery as well.
But that is not all. Criteria may hold queries as well (subqueries).
Looking at the criteria implementations for IN-clauses en
EXISTS-clauses, I observe that both classes (InCriterion and
ExistsCriteria) do not implement proper preprocess-methods. So using
subqueries (in the way I described earlier with the IN-clause) will also
throw exceptions because of missing where clauses. So I think a
preprocess method should be added to those classes as well, something
like:
/**
* Preprocess the Criterion using a PersistenceBroker.
*
* @param aPb the PersistenceBroker
*/
public void preprocess(PersistenceBrokerInternal aPb)
{
if (getValue() instanceof Query)
{
((Query)getValue()).preprocess(aPb);
}
}
So, these were my thoughts. I do not know if I am completely correct, or
if I am missing some essential things But when I apply these patches
in combination with the earlier patch in BrokerHelper All the bugs
reagrding the count queries and the IN- and EXISTS-clauses are gone! In
my testsuite of our own persistencewrapper around OJB that is :).
Hope this helps.
Yes, indeed! A brilliant analysis. I'm not very familiar with the query
stuff, so I will accept all of your suggestions and see what happens.
regards,
Armin
I have some more exceptions in my testsuite but I am analyzing them.
When the cause is a bug in 1.0.5rc1, you'll hear.
Greetings,
Roger Janssen
iBanx
*
The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference.
If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies.
-
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: Mapping for type BIT broke afer upgrade from 1.0.1 to 1.0.4
Hi Oliver, Oliver Seimel wrote: Hi, we migrated from ojb 1.0.1 to 1.0.4 DB is Postgres. But I think, that the "problem" is independent of the DB. We use the type BIT(1) for boolean values, so a mapping looks like this: With version 1.0.1 the generated SQL was ... WHERE emailnotice = '1' . With version 1.0.4 the generated SQL is ... WHERE emailnotice = 'true' . Thats not good, because the statement fails. Does anybody know why ojb now maps the BIT types to BOOLEAN? OJB 1.0.4 and higher try to support the JDBC 3.0 specification which specify to map BIT to boolean http://db.apache.org/ojb/docu/guides/jdbc-types.html Maybe this cause your problem. Could you please post the query/criteria which produce the SQL shown above. regards, Armin Thank you very much Oliver - 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: BUGREPORT : OJB 1.0.5 release candidate 1 (unofficial)
Hi Roger,
thanks for testing the upcoming 1.0.5 release.
Janssen, Roger wrote:
Hi,
Like a reported earlier, something goes wrong with count queries.
I can reproduce this bug (thanks for detailed description).
When I hack some code in BrokerHelper, to get around the first bug (I
don't know if what I do is correct, but I am trying):
private Query getReportQueryByCriteriaCount(ReportQueryByCriteria
aQuery)
{
Query cQuery = (Query) getQueryByCriteriaCount(aQuery);
ReportQueryByCriteria countQuery = null;
if(cQuery.getClass().isAssignableFrom(ReportQueryByCriteria.class))
{
countQuery = (ReportQueryByCriteria) cQuery;
}
else
{
countQuery = (ReportQueryByCriteria)((EnclosingReportQuery)
cQuery).getQuery();
}
// BRJ: keep the original columns to build the Join
countQuery.setJoinAttributes(aQuery.getAttributes());
// BRJ: we have to preserve groupby information
Iterator iter = aQuery.getGroupBy().iterator();
while(iter.hasNext())
{
countQuery.addGroupBy((FieldHelper) iter.next());
}
return cQuery;
}
Then i do not get any class cast exceptions anymore.
I tried the same solution a few minutes ago. This seems fix the bug - my
local test to reproduce the bug pass and no new failures/error occur.
But something is still fishy about the counts in combination with
IN-clauses. It looks like the count query has lost its where clauses
when I have IN-clauses in the query.
ok, that's bad luck. I will try to reproduce this new problem too.
regards,
Armin
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR:
org.apache.ojb.broker.PersistenceBrokerSQLException:
The root stack trace is -->
* SQLException during execution of sql-statement:
java.sql.SQLException: Not a condition in statement [select count(*)
from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc]
* sql statement: select count(*) from (SELECT DISTINCT A0.ID FROM
IBANX_PERMIT A0 WHERE null ) ojb_enc
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
* Exception message: Not a condition in statement [select count(*) from
(SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc]
at org.hsqldb.jdbc.jdbcPreparedStatement.executeQuery(Unknown
Source)
* Vendor error code: -106
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown
Source)
* SQL state code: S1000
at
org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown
Source)
**
at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown
Source)
at
org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknown
Source)
at
org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown
Source)
at
org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterator(
Unknown Source)
at
org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(
Unknown Source)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIteratorF
romQuery(Unknown Source)
at
org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIteratorB
yQuery(Unknown Source)
at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCount(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown
Source)
at
org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterator(
Unknown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(
Unknown Source)
Greetings,
Roger Janssen
iBanx
*
The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference.
If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies.
--
Re: OJB 1.0.5 release candidate 1 (unofficial)
Hi Ilkka, Ilkka Priha wrote: Thanks Armin! Seems to work great with our app (MySQL-NT). Thanks for testing! The only found inconsistency with the previous version was that the default CopyStrategyImpl in ObjectCacheTwoLevelImpl is now final. We apply dynamic persistent Variables, which must be cloned during copying, and have implemented their special treatment in a subclass of CopyStrategyImpl. Now we have to copy the whole class instead of subclassing it to support both normal persistent objects and dynamic variables within the same strategy. Are there specific reasons to have a final copy strategy? Nope! Seems my code improvement goes over the top ;-) I will fix this and revert CopyStrategyImpl to a non-final class. regards, Armin Regards, Ilkka Armin Waibel wrote: Hi all, I have uploaded a first (unofficial) release candidate of the upcoming OJB 1.0.5 version. The source distribution can be found here: http://people.apache.org/~arminw/ Please give it a go and report any bugs. The source distribution contains a compiled OJB jar and the full html-documentation (of the upcoming 1.0.5). Further information can be found in the readme and release-notes files (recommended to read both files). If there are no bugs, I think 1.0.5 can be released within the next two or three weeks. regards, Armin - 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]
OJB 1.0.5 release candidate 1 (unofficial)
Hi all, I have uploaded a first (unofficial) release candidate of the upcoming OJB 1.0.5 version. The source distribution can be found here: http://people.apache.org/~arminw/ Please give it a go and report any bugs. The source distribution contains a compiled OJB jar and the full html-documentation (of the upcoming 1.0.5). Further information can be found in the readme and release-notes files (recommended to read both files). If there are no bugs, I think 1.0.5 can be released within the next two or three weeks. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locking entire table
Hi JohnE, johne wrote: I am using the OJB 1.0.3 PB with MySql 5.0. I have a series of processes that work off of a common table. This common table is refreshed regularly. During this refresh, I would like to do to the affect of: 1. Begin a transaction. 2. Lock the entire table. 3. Delete entire table. 4. Unlock entire table. 5. End transaction. While a single process on a single server does this, it would be great if the other read only processes seeking to use it were to fail fast with exception. Can anybody give me an example on how to do this? So far I have to the affect of: Query query = new QueryByCriteria(objectClass, null); broker.beginTransaction(); broker.deleteByQuery(query); broker.commitTransaction(); I am not sure how to do the fail fast table level locking. I'm not sure that I get your point. Doesn't this depend on the database isolation level? Or do you want to lock a database table by hand before deleting all rows? regards, Armin I feel I am missing other things as well. I can use some help filling in the gaps. If you have a better idea on how to implement, I am open. I was thinking I could just put a locking record in another table, but thought this might be better. Thanks for any help. JohnE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scaling
Hi JohnE, johne wrote: We have been using OJB for a long time for http://www.jobbank.com, but we are working on a revised version of the job site for a new country. The application needs to be able to scale in a potentially massive way. I am looking at different distributed caching strategies and am looking for opinions on what might work best with OJB. Terracotta is interesting because it seems scalable without the big distributed hits that other caching mechanisms seem to get, but I am still very much at the start of this all and can use any ideas possible on how best to scale a OJB solution. OJB is shipped with a simple multi threaded performance test: http://db.apache.org/ojb/docu/guides/performance.html#OJB+performance+in+multi-threaded+environments If you write your own ObjectCache implementation this could help to check performance. The OJB cache works in two ways: 1. If you do a "lookup by identity" or "query by identity" http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+primary+key OJB can lookup the object in the cache without a database roundup. 2. A query will always lead to a DB roundup. OJB build the object identity from the result set and checks against the cache. If not in the cache OJB materialize the full object from the result set, otherwise the cached object is returned. If the queries vary much (many different keyword/keyword combinations) OJB's cache doesn't help much. In this case a "fast" database server (and OJB with a session cache/ "per broker cache") will increase the performance of the whole application more then a distributed cache. All in all OJB seems to scale very well in multi threaded environments. For the upcoming 1.0.5 version (I will provide the 1.0.5rc1 tomorrow) I run OJB's performance test against other popular persistence layer and OJB looks fine - but I have to admit that this test is too simply to allow a general rating. regards, Armin Though I do not write often, I am always following the development boards and user boards here and thank you for your efforts Armin. JohnE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Isolation level
Hi Christian, Christian Lipp wrote: I am still looking for an solution for my lock level settings and therefore I am digging through the OJB source. What I am not sure at the moment is if the setting of the isolation-level is generally ignored in OJB? I couldn't find the place in the OJB code where the isolation level is set to the DescriptorRepository and later to the connection. In my optionion the isolation-level in the XML file is ignored. Could someone point me in the right direction? Out of the box the isolation-level setting is only used by the ODMG-api which use pessimistic locking by default. http://db.apache.org/ojb/docu/guides/lockmanager.html#Pessimistic-Locking The PB-api doesn't use pessimistic locking, thus it will ignore these settings. The database transaction levels are completely independent from the isolation-level setting in OJB. So you can use different database transaction levels (e.g. as property in the dbalias attribute in the jdbc-connection-descriptor) regards, Armin Thanks in advance, CL - 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]
[off topic] Hey Guys!
...sorry for the delay and my "unauthorized absence" ;-) Six weeks ago our daughter was born and till now I can't spend time on OJB - "baby-logistics" is a full time job and these days I enjoy staring at the baby instead of the computer-screen. I will be back soon. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy collection and cyclic references
Hi Robert, Robert Giddings wrote: Hi Armin, Actually it doesn't seem to have anything to do with Proxies as setting proxy to false while leaving auto-retrieve to true creates the same problem. As for code enhancements, there are none. All my code is doing is reading out an object from the database which has encrypted fields. I then run the decrypt method of that object to produce a decrypted version. The collections aren't decrypted, but rather assigned to the new object, allowing for proxy collections. When their access method is called their member objects are decrypted. Each collection member object has a parent reference to the owner object of the collection and the decrypt method is run on this object when the collection member object is decrypted. However instead of stopping in the loop because eventually the loop gets to a null as is the case with all the other collections one of the collections keeps on looping until a StackTraceOverflow. For me it's difficult to figure this out without reading your sources. In OJB the class responsible to materialize query/collection objects is ...accesslayer.RsIterator.java. RsIterator use class MaterializationCache to avoid endless loops on cyclic object graph materialization. Maybe this can help you to solve the problem. I have looked at my code, but it is identical to the code for the decrypting of the other collections, leading me to believe that this is an error with OJB in regard to cyclic references. It seems we reached an impasse ;-) If OJB cause your problem it's mandatory for me to reproduce your problem - only this way I can fix it. So please could you send me an test to reproduce the problem (keep the test as simple as possible, remove all unneeded fields, classes... If OJB cause the problem you should be able to write an test without using your en/decrypt methods, only 'normal' objects with cyclic references). regards, Armin Rob -----Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 13 November 2007 11:28 To: OJB Users List Subject: Re: Proxy collection and cyclic references Hi Robert, Robert Giddings wrote: Hi Guys, Has anyone had any trouble with a proxy collection and cyclic references before? I keep getting StackTraceOverflow errors because of an infinite loop where a collection of objects of one type has a reference to the collection owner object. However I can't see this as being a problem with my code, because I have looked all over the place for an error, but my code in the decrypt method of the objects class is identical to other classes, and they don't have any problem. Could you reproduce this error if you remove your enhancements (if exist)? If yes, please open an issue https://issues.apache.org/jira/browse/OJB and describe detailed (e.g. with pseudo code) how to reproduce your problem. If possible please run your test against the latest version from SVN (OJB_1_0_RELEASE branch) - it's stable and will be the 1.0.5rc1. The OJB test-suite run several tests with cyclic references and they all pass, so I would expect that this error (if it's one) already fixed in SVN. regards, Armin Thanks, Rob - 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: Proxy collection and cyclic references
Hi Robert, Robert Giddings wrote: Hi Guys, Has anyone had any trouble with a proxy collection and cyclic references before? I keep getting StackTraceOverflow errors because of an infinite loop where a collection of objects of one type has a reference to the collection owner object. However I can't see this as being a problem with my code, because I have looked all over the place for an error, but my code in the decrypt method of the objects class is identical to other classes, and they don't have any problem. Could you reproduce this error if you remove your enhancements (if exist)? If yes, please open an issue https://issues.apache.org/jira/browse/OJB and describe detailed (e.g. with pseudo code) how to reproduce your problem. If possible please run your test against the latest version from SVN (OJB_1_0_RELEASE branch) - it's stable and will be the 1.0.5rc1. The OJB test-suite run several tests with cyclic references and they all pass, so I would expect that this error (if it's one) already fixed in SVN. regards, Armin Thanks, Rob - 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: Maps
Hi Robert,
Robert Giddings wrote:
Hi Armin,
UserType is a complex object that is used as a property in other
objects. AccessRight is an enum.
The XDoclet I currently have is:
/**
* @ojb.field jdbc-type="LONGVARCHAR"
conversion="org.apache.ojb.broker.accesslayer.conversions.Object2Base64S
tringFieldConversion"
*/
private EnumMap accessRights =
new EnumMap(AccessRight.class);
I was just wondering if there is a better way of converting this
property?
hmm, you can write your own FieldConversion to optimize conversion
performance (java --> sql and vice versa).
E.g. persist key-value string ("read=true,write=true,delete=false") or
only the values ("110") instead of the whole object.
An alternative would be a nested object
http://db.apache.org/ojb/docu/guides/advanced-technique.html#Nested+Objects
with a Boolean field for each AccessRight. But a 'nested object' need a
default constructor and it will be tricky to realize it with
EnumMap. The advantage of a nested object is that
you can search for each field (of a nested object) in queries.
regards,
Armin
Thanks,
Robert Giddings
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 28 September 2007 16:40
To: OJB Users List
Subject: Re: Maps
Robert Giddings wrote:
Also forgot to mention, what I really want is the XDoclet code that
can
be used with Maps.
Sorry, I don't get it. How are UserType and AccessRight associated
(1:n?)?
Armin
Robert
-Original Message-
From: Robert Giddings [mailto:[EMAIL PROTECTED]
Sent: 28 September 2007 14:28
To: 'OJB Users List'
Subject: RE: Maps
Hi Armin,
This is the Map in question:
private EnumMap accessRights =
new EnumMap(AccessRight.class);
It is just a data member field in an object called UserType.
Thanks,
Robert
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 28 September 2007 14:00
To: OJB Users List
Subject: Re: Maps
Hi Robert,
Robert Giddings wrote:
Hi,
Does anyone know if and how OJB can handle Maps?
can you describe more detailed what you want to do - using maps in 1:n
or m:n references, direct persist maps, ...
regards,
Armin
Thanks,
Rob
-
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: deprecated LockManagerClass
Hi Robert, Robert den Uijl wrote: Hi, Regarding migration ojb 1.0.1 to 1.0.4 I noticed the following line in ojb.properties # @deprecated LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl If I retain this setting a NPE occurs in the doClose() invoke in org.apache.ojb.odmg.TransactionImpl.commit() The NPE doesn't occur when changing the LockManagerClass implementation to: LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl did you uncomment the LockMapClass entry too? However I could not found any information about the reason of org.apache.ojb.odmg.locking.LockManagerDefaultImpl being deprecated; I would like to know the impact of using the other implementation. So, what is the reason behind this change? The locking stuff moved from the odmg-package to the OJB core to allow future API's (e.g. JPA or enhanced PB-api) use of the core locking-api. Additionally initial support for commons-transaction locking api and code review, bug fixes. regards, Armin Regards, Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Different behaviour of SequenceManager in rc5 and 1.0.1
Christian Eugster wrote:
Hi Armin,
thank you for the hint. Now I have changed all the id field's default
value of my objects to null instead of '0'. I updated OJB to 1.0.4
now (good luck!). When I try to store an object I get now the
following Exception:
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR:
PersistenceBrokerException during the execution of materializeObject:
Can't generate primary key values for given Identity
org.apache.ojb.broker.util.sequence.HighLowSequence{SEQ_pos_product_group}
Can't generate primary key values for given Identity
org.apache.ojb.broker.util.sequence.HighLowSequence{SEQ_pos_product_group}
[org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl]
ERROR: Can't lookup new HighLowSequence for field id using sequence
name SEQ_pos_product_group Can't generate primary key values for
given Identity
org.apache.ojb.broker.util.sequence.HighLowSequence{SEQ_pos_product_group}
As I see in the documentation the table ojb_hl_seq has only changed
the type of max_key from Integer to Bigint.
and removed a deprecated column
Is there another place
where I have to look?
In the release-notes (especially section 'notes' and 'changes').
Don't forget to replace the old repository_internal.xml (and all other
OJB config files) file with the new one shipped with 1.0.4.
regards,
Armin
Thanks!
Christian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Different behaviour of SequenceManager in rc5 and 1.0.1
Christian Eugster wrote: Hi Armin, DBResult is useless (an older story). The object is written to the database (a mysql 5.0 database). But the primary key always the value '0'. When I change back to version 1.0.rc5 the values are assigned. I checked the source in OJB 1.0.4, the PK will be assigned on insert of the object (if the PK field value is 'NULL': 0 for primitiv field (int long,...), 'Null' for non-primitiv). See this class (scroll to the end): http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/accesslayer/JdbcAccessImpl.java?revision=365204&view=markup Are the PK fields initialized with non-Null values? When do you request the PK value of your object? Is it definitely after insert of the object? regards, Armin Regards Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Different behaviour of SequenceManager in rc5 and 1.0.1
Hi Christian,
the mapping seems ok. What I don't understand is the use of DBResult.
You create a new instance of DBResult before "this" is stored by OJB and
the DBResult instance never change - why?
Does OJB writes the object to the database?
>> record the sequence manager does not assign a value to my primary
>> key
How did you check this (you don't post this)?
regards,
Armin
Christian Eugster wrote:
The mapping part ist as follows:
(but the same problem is for every class/table)
the code saving a new Object is:
public DBResult store(Connection connection) {
PersistenceBroker broker = connection.getBroker();
DBResult result = new DBResult();
boolean isMyTransaction = !broker.isInTransaction();
try {
if (isMyTransaction) {
broker.beginTransaction();
}
broker.store(this);
if (isMyTransaction) {
broker.commitTransaction();
}
}
catch (PersistenceBrokerException e) {
if (isMyTransaction) {
broker.abortTransaction();
}
if (e instanceof ClassNotPersistenceCapableException) {
testSwitchDatabase();
}
else if (isMyTransaction) {
result = describeError(e);
if (e instanceof PersistenceBrokerSQLException)
{
PersistenceBrokerSQLException psqle =
(PersistenceBrokerSQLException) e;
if (psqle.getSourceException()
instanceof SQLException) {
SQLException sqle =
(SQLException) psqle.getSourceException();
//result = describeError(sqle);
// if
(sqle.getSQLState().equals("08S01")) { //$NON-NLS-1$
testSwitchDatabase();
// }
}
}
}
}
return result;
}
and the code that sets the connection is:
public void setConnection(JdbcConnectionDescriptor cd, Element el) {
cd.setJcdAlias(el.getAttributeValue("jcd-alias")); //$NON-NLS-1$
cd.setDefaultConnection(Boolean.getBoolean(el.getAttributeValue("default-connection")));
//$NON-NLS-1$
cd.setDbms(el.getAttributeValue("platform")); //$NON-NLS-1$
cd.setJdbcLevel(el.getAttributeValue("jdbc-level"));
//$NON-NLS-1$
cd.setDriver(el.getAttributeValue("driver")); //$NON-NLS-1$
cd.setProtocol(el.getAttributeValue("protocol")); //$NON-NLS-1$
cd.setSubProtocol(el.getAttributeValue("subprotocol"));
//$NON-NLS-1$
StringBuffer sb = new StringBuffer("//"); //$NON-NLS-1$
sb.append(el.getAttributeValue("host")); //$NON-NLS-1$
sb.append(":"); //$NON-NLS-1$
sb.append(el.getAttributeValue("port")); //$NON-NLS-1$
if (el.getAttributeValue("database").length() > 0) {
//$NON-NLS-1$
sb.append("/"); //$NON-NLS-1$
sb.append(el.getAttributeValue("database"));
//$NON-NLS-1$
}
sb.append(el.getAttributeValue("options")); //$NON-NLS-1$
// cd.addAttribute("autoReconnect", "true");
cd.setDbAlias(sb.toString());
cd.setUserName(el.getAttributeValue("username")); //$NON-NLS-1$
cd.setPassWord(el.getAttributeValue("password")); //$NON-NLS-1$
cd.setBatchMode(Boolean.getBoolean(el.getAttributeValue("batch-mode")));
//$NON-NLS-1$
cd.setUseAutoCommit(Integer.parseInt(el.getAttributeValue("use-auto-commit")));
//$NON-NLS-1$
ConnectionPoolDescriptor cpd = cd.getConnectionPoolDescriptor();
SequenceDescriptor sd = new SequenceDescriptor(cd);
sd.setSequenceManagerClass(org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl.class);
sd.addAttribute("grabSize", "20");
}
Thanks
Christian
Original-Nachricht -
Re: Maps
Robert Giddings wrote: Also forgot to mention, what I really want is the XDoclet code that can be used with Maps. Sorry, I don't get it. How are UserType and AccessRight associated (1:n?)? Armin Robert -Original Message- From: Robert Giddings [mailto:[EMAIL PROTECTED] Sent: 28 September 2007 14:28 To: 'OJB Users List' Subject: RE: Maps Hi Armin, This is the Map in question: private EnumMap accessRights = new EnumMap(AccessRight.class); It is just a data member field in an object called UserType. Thanks, Robert -Original Message----- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: 28 September 2007 14:00 To: OJB Users List Subject: Re: Maps Hi Robert, Robert Giddings wrote: Hi, Does anyone know if and how OJB can handle Maps? can you describe more detailed what you want to do - using maps in 1:n or m:n references, direct persist maps, ... regards, Armin Thanks, Rob - 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: Different behaviour of SequenceManager in rc5 and 1.0.1
Hi Christian, Christian Eugster wrote: Hi, In my program I updated ojb from 1.0.rc5 to 1.0.1. When I store a new record the sequence manager does not assign a value to my primary key field (autoincrement=true). With 1.0.rc5 it did it (and does it) with no problem. With 1.0.4 too there is no assigning to the autoincrement field. I use org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl as Sequence Manager. Has anybody any suggestion, what i can do? Please post the mapping (class-descriptor) of the related class and a code snip or pseudo code of the related source code (insert of the object). regards, Armin Thanks a lot! Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to clear cache
Alessandro Colantoni wrote:
I think you are using the cache ObjectCachePerBrokerImpl.
Or the recommended two-level cache which has a session cache too.
In the method findbroker to put a condition that if the entry of
Mandragora.properties broker.useUserBroker is true, return the userbroker in
place of create a new broker.
And in all methods of OjbPbDAO , when they close the broker, put a
condition that if broker.useUserBroker = true don't close, else close.
So it is user responsibility to create and close the broker.
With all of this your code should work. Of course remember to close the
broker.
Someone else (Armin? )agree with this?
I hope have been clear enough.
If OjbPbDAO can differ between user-PB and new-PB this should work, else
a user got problems when using both strategies - e.g. most times
inject a user-PB, but from time to time using the ServiceLocator without
injection of a user-PB (e.g. with default settings, based on the current
PBKey, to perform a simple query).
In general, I think implementing ServiceLocator and DAO as singletons
cause some drawbacks, because singletons make it impossible to use
different PBKey (e.g. different databases) in the same
web-project/application or in a multi-threaded environment.
If ServiceLocator isn't a singleton it can have a state (e.g. the user
can specify a PBKey to force creation of specific PB instances).
regards,
Armin
Anyway Hans, download the source, and have a look, so you can help. look at
the OjbDAO methods.
They just use Ojb so it is very easy and we can solve this together.
if you and Armin agree I start as soon as possible, even if I'm going on
travel tomorrow until October the 3th
Thanks
and regards
Alessandro
On 9/26/07, Hans Novak <[EMAIL PROTECTED]> wrote:
Hi Allesandro,
i think im stupid - or - how we in germany say: i dont see the wood for
the trees ... ;-)
im my (ojb) dao class i use
public class PartnerFactoryCore {
private PersistenceBroker broker = null;
static Logger logger = Logger.getLogger("osf");
public PartnerFactoryCore() {
try {
broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
} catch (Exception e) {
e.printStackTrace();
MsgBoxHn.msgBoxOK(e.getMessage().toString() +
"\n\n\nProgrammende.");
System.exit(0);
}
}
}
I use mandragora for example to store an object like this:
private void saveData(){
formPartner = getPartnerFromForm();
LOGGER.debug("Data Saving...");
//old way!!! - do not delete objects in the collection tree
//partnerFactoryCore.store(formPartner); //from
// new Way with mandragora
try {
BD bd =
ServiceLocator.getInstance
().getManagerBD("BDFactoryDefaultClass","StandardBDDefaultClass");
bd.updateCollectionReferences(formPartner);
} catch (Exception e) {
e.printStackTrace();
}
LOGGER.debug(formPartner.toString(0));
}
how can i put this 2 things together ?
Hans
-
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: Maps
Hi Robert, Robert Giddings wrote: Hi, Does anyone know if and how OJB can handle Maps? can you describe more detailed what you want to do - using maps in 1:n or m:n references, direct persist maps, ... regards, Armin Thanks, Rob - 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: how to clear cache
Armin Waibel wrote: (...and it's correct) But if you want to take advantage from a session cache on multi findByPrimaryKey calls of the same id or you have to store hundreds of objects it's a bit a "performance anti pattern" to close the PB instance on each method call (this evicts the session cache) or to perform the tx-cycle for each object (this way you can't rollback the whole operation if something went wrong). Think it would be useful to allow some kind of PB "inject" in the DAO implementation (direct or indirect via ServiceLocator) and the DAO never close the "inject" PB instance. On insert, update, delete the DAO implementation: -force a PB-tx (if not running start one and commit/rollback, if running don't commit at the end) -or throw an exception if no tx is running on the "inject" PB (more transparent). But never allow object modification without a running tx. Seems I was too late. As I can see you post a similar suggestion a few minutes before my post. Armin regards, Armin Anyway remember that Mandragora works with the interface DAO, and if you think in a better way can be done, we could write an other DAO implementation, and it is used just changing the correspondent entry in Mandragora.properties Regards Alessandro On 9/25/07, Hans Novak <[EMAIL PROTECTED]> wrote: PersistenceBroker.clearCache(); to evict the whole cache yes, this works, but will increase the database access a lot. You speaks about the possibility, that ojb and mandragora can use the same PB ... how ? I have a dao class, with the broker. This broker is private and will not used in any other classes !? The other way is to clear only the obj with a oid - but what for oid ? (a uniqe id from a filed in database ?) But this operation willincrase the access to the db too The better way is to use the same broker, i think. Hans - 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: how to clear cache
Hi Alessandro, Alessandro Colantoni wrote: Hi, When you use OjbPbDAO of Mandragora, in each method it does (through the ServiceLocator) PersistenceBroker broker broker= PersistenceBrokerFactory.defaultPersistenceBroker(); than at the end of the method it does broker.close(); I understand that each time it is used a different PB. I think it is right. For each transaction I get a broker use it and then close. That's the way my OjbPbDAO works. (...and it's correct) But if you want to take advantage from a session cache on multi findByPrimaryKey calls of the same id or you have to store hundreds of objects it's a bit a "performance anti pattern" to close the PB instance on each method call (this evicts the session cache) or to perform the tx-cycle for each object (this way you can't rollback the whole operation if something went wrong). Think it would be useful to allow some kind of PB "inject" in the DAO implementation (direct or indirect via ServiceLocator) and the DAO never close the "inject" PB instance. On insert, update, delete the DAO implementation: -force a PB-tx (if not running start one and commit/rollback, if running don't commit at the end) -or throw an exception if no tx is running on the "inject" PB (more transparent). But never allow object modification without a running tx. regards, Armin Anyway remember that Mandragora works with the interface DAO, and if you think in a better way can be done, we could write an other DAO implementation, and it is used just changing the correspondent entry in Mandragora.properties Regards Alessandro On 9/25/07, Hans Novak <[EMAIL PROTECTED]> wrote: PersistenceBroker.clearCache(); to evict the whole cache yes, this works, but will increase the database access a lot. You speaks about the possibility, that ojb and mandragora can use the same PB ... how ? I have a dao class, with the broker. This broker is private and will not used in any other classes !? The other way is to clear only the obj with a oid - but what for oid ? (a uniqe id from a filed in database ?) But this operation willincrase the access to the db too The better way is to use the same broker, i think. Hans - 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: how to clear cache
Hi Hans, Hans Novak wrote: Hi Ng, i use allesandros mandragora with ojb in "mixed-mode". It is working fine, but when i remove objects with mandragora and then read the again with ojb, i get the cached object back, not the one, what hase been saved. When i restart my app, then i get the right object. So, how can i clear the ob cache (or whatever, to get the right data :-) ) ? You can use PersistenceBroker.clearCache(); to evict the whole cache PersistenceBroker.serviceObjectCache().remove(Identity oid); remove a specific object Take care that all insert/update/delete operations are performed within a running transaction, else the cache will be corrupted. Take care that mandragora use your current PB instance or get a new PB instance after using mandragora (to avoid session cache issues). All "delete by query" stuff (PB.deleteByQuery) doesn't synchronize with the cache. regards, Armin Hans - 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: storing objects
Hi Sergey, Manukyan, Sergey wrote: Hi Armin, Can I be included on that list? yep! You only have to subscribe. http://db.apache.org/ojb/mail-lists.html And how to become the developer/contributor of OJB in general? Everyone can be a developer, all contributors are developer. http://apache.org/foundation/how-it-works.html#developers If you have code or documentation to contribute make your suggestion on the dev-list. Then we (OJB developer + committer) can discuss whether or not to accept the contribution/suggestion. If a developer constant contributes code/doc, participate in discussions and help other user on the mail lists a committer can suggest this developer to become a committer. regards, Armin Thanks, -Sergey -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday, September 14, 2007 8:00 PM To: OJB Users List Subject: Re: storing objects Hi Sergey, Manukyan, Sergey wrote: Hi, About mandragora... it looks like it is a layer on top of PerstenceBroker... my suggestion would be why not to integrate it into OJB and call it something like Simplified API for Persistance Broker (SAP)... ? I only checked the methods of the it.aco.mandragora.dao.DAO interface. If OJB user find these methods useful I agree to integrate it (in some way) in OJB. I suggest to discuss the details on the dev-list. regards, Armin It will help improve OJB in the next releases. As frankly speaking I see a need in it, as I myself developed some kind of OJB façade class that simplifies OJB operations with a simplified API. Just my 2 cents, -Sergey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** ** LEGAL DISCLAIMER ** ** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. - 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: getPKEnumerationByQuery()
Hi Robert,
Robert Giddings wrote:
Hi,
When using the method getPKEnumerationByQuery() I get the following
error:
Caused by: java.util.NoSuchElementException
at
org.apache.ojb.broker.accesslayer.PkEnumeration.nextElement(Unknown S
ource)
at
com.netcase.database.DAOService.getIdsByPropertyMatch(DAOService.java
:117)
Has anyone else had any problems using OJB's Enumeration implementation?
As the code that iterates through it is this:
Enumeration pks = broker.getPKEnumerationByQuery(PrimaryKey.class,
query);
Collection ids = new
ArrayList();
while(pks.hasMoreElements()) {
PrimaryKey pk =
(PrimaryKey)pks.nextElement();
ids.add(pk.getId());
}
And I can't see any problem with this code, and so can only conclude
that the hasMoreElements() or nextElement() method was not implemented
correctly.
Please check OJB's logging output. Any error log before the
NoSuchElementException?
By the way, this class is now deprecated because nobody seems to use it.
If you need the PK values to create a user specific PrimaryKey class I
would recommend (for best performance) a report query to get all PK's.
regards,
Armin
Thanks,
Robert Giddings
-
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: n:m mapping problem
Hi Truong, seems that the Apache server removed the attached files. Could you please send the source code as normal text? By the way the generated DB seems to be consistent, so the problem was caused by OJB or "wrong usage" of OJB. regards, Armin Truong Nguyen Huy wrote: Thank you very much for your attention to my problem. I am sorry not supply full detail for you to test the problem. Let me put straight my issue. Here is the script to create database (MySQL): --- # MySQL-Front 3.2 (Build 14.8) /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES latin1 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='SYSTEM' */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE */; /*!40101 SET SQL_MODE='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES */; /*!40103 SET SQL_NOTES='ON' */; # Host: localhostDatabase: test # -- # Server version 5.0.41-community-nt DROP DATABASE IF EXISTS `test`; CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */; USE `test`; # # Table structure for table car # CREATE TABLE `car` ( `id` int(10) unsigned NOT NULL auto_increment, `licencenum` varchar(45) NOT NULL, `personid` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `FK_car_1` (`personid`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table car # INSERT INTO `car` VALUES (1,'52S4-1800',1); INSERT INTO `car` VALUES (2,'52S4-9448',1); INSERT INTO `car` VALUES (3,'50L1-2381',2); # # Table structure for table person # CREATE TABLE `person` ( `id` int(10) unsigned NOT NULL auto_increment, `name` varchar(45) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table person # INSERT INTO `person` VALUES (1,'Truong'); INSERT INTO `person` VALUES (2,'Tuan'); INSERT INTO `person` VALUES (3,'Nguyen'); INSERT INTO `person` VALUES (4,'Tam'); # # Table structure for table project # CREATE TABLE `project` ( `id` int(10) unsigned NOT NULL auto_increment, `Name` varchar(45) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table project # INSERT INTO `project` VALUES (1,'EdenTree'); INSERT INTO `project` VALUES (2,'Simpatica'); # # Table structure for table project_person # CREATE TABLE `project_person` ( `project_id` int(10) unsigned NOT NULL default '0', `person_id` int(10) unsigned NOT NULL default '0', PRIMARY KEY (`project_id`,`person_id`), KEY `FK_project_person_1` (`person_id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # # Dumping data for table project_person # INSERT INTO `project_person` VALUES (1,1); INSERT INTO `project_person` VALUES (1,3); INSERT INTO `project_person` VALUES (2,1); INSERT INTO `project_person` VALUES (2,2); INSERT INTO `project_person` VALUES (2,3); INSERT INTO `project_person` VALUES (2,4); # # Foreign keys for table car # ALTER TABLE `car` ADD FOREIGN KEY (`personid`) REFERENCES `person` (`id`); # # Foreign keys for table project_person # ALTER TABLE `project_person` ADD FOREIGN KEY (`person_id`) REFERENCES `person` (`id`), ADD FOREIGN KEY (`project_id`) REFERENCES `project` (`id`); /*!40111 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40103 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; /*!40101 SET [EMAIL PROTECTED] */; I have attached the source code. Please find it in the attachment. Here is the list of library I use: commons-collections-3.1.jar commons-dbcp-1.2.1.jar commons-lang-2.1.jar commons-pool-1.2.jar commons-transaction-1.1.jar commons-logging-1.0.4.jar db-ojb-1.0.4.jar mysql-connector-java-5.0.7-bin.jar log4j-1.2.8.jar OJB version that I use: 1.0.4. I download from a mirror location of Apache OJB Thanks for your help, Regards, Truong Nguyen On 9/7/07, Armin Waibel <[EMAIL PROTECTED] > wrote: Hi, your mapping seems ok. Sounds like a bug in OJB. I tried to reproduce your problem without success (using latest version of OJB from SVN OJB_1_0_RELEASE branch) - never get a NPE. I use the mapping from the m:n example (with Person and Project) and do: oid = broker.serviceIdentity().buildIdentity(Person.class, new Integer(1)); person = (Person) broker.getObjectByIdentity(oid); No NPE. How can I reproduce your problem? regards,
Re: storing objects
Hi Sergey, Manukyan, Sergey wrote: Hi, About mandragora... it looks like it is a layer on top of PerstenceBroker... my suggestion would be why not to integrate it into OJB and call it something like Simplified API for Persistance Broker (SAP)... ? I only checked the methods of the it.aco.mandragora.dao.DAO interface. If OJB user find these methods useful I agree to integrate it (in some way) in OJB. I suggest to discuss the details on the dev-list. regards, Armin It will help improve OJB in the next releases. As frankly speaking I see a need in it, as I myself developed some kind of OJB façade class that simplifies OJB operations with a simplified API. Just my 2 cents, -Sergey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overriding the ProxyList class
Hi Robert,
Robert Giddings wrote:
The line " but this isn't really practical as I can
override methods such as indexOf(Object o) as they rely on equals."
Should read "can't override methods" because of relying on equals.
Anyway, seems as if the ojb methods are never called as I put some
System.out.println() statements in all the methods, and the constructor
and getter/setters get called OK, but the ojb methods never print out
anything.
Why would they never get called?
I think OJB doesn't know about the List proxy class or do you declare
this class as List/Collection/(Set) proxy in OJB.properties file?
You can't declare specific collection proxy classes per 1:n, m:n
reference only a general for all Collection, List and Set references.
regards,
Armin
Robert Giddings
-Original Message-
From: Robert Giddings [mailto:[EMAIL PROTECTED]
Sent: 13 September 2007 10:16
To: 'OJB Users List'
Subject: Overriding the ProxyList class
Hi,
Can anyone please tell me why this code doesn't seem to have an effect?
That is I get a class cast exception because an encrypted object for
example EncryptedCostCentre does not get decrypted to a CostCentre. Both
classes implement an interface called ICostCentre, but this interface
has no method signatures etc as the structure of the two classes is
different. I.e. CostCentre has getter/setters and EncryptedCostCentre
has an encrypt and decrypt methods.
The concept works fine, if I override the java.util.List methods and
encrypt and decrypt there, but this isn't really practical as I can
override methods such as indexOf(Object o) as they rely on equals.
The cypherMachine and encryptedClassType are set in the decrypt method
of the owner object, where a reference to the ICostCentre collection is
passed to the decrypted version of that object.
Also what changes am I likely to need to make to the afterStore method?
Thanks,
Robert Giddings
The code:
package com.netcase.database.ojb.proxy;
import java.lang.reflect.Method;
import java.util.Iterator;
import org.apache.ojb.broker.ManageableCollection;
import org.apache.ojb.broker.PBKey;
import org.apache.ojb.broker.PersistenceBroker;
import org.apache.ojb.broker.PersistenceBrokerException;
import org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl;
import org.apache.ojb.broker.query.Query;
import com.netcase.encryption.CypherMachine;
public class EncryptableCollectionProxy extends ListProxyDefaultImpl {
private CypherMachine cypherMachine;
private Class encryptedClassType;
public EncryptableCollectionProxy(PBKey brokerKey,
java.lang.Class collClass, Query query) {
super(brokerKey, collClass, query);
cypherMachine = null;
encryptedClassType = null;
}
public EncryptableCollectionProxy(PBKey brokerKey, Query query)
{
super(brokerKey, query);
cypherMachine = null;
encryptedClassType = null;
}
/**
* @return the cypherMachine
*/
public CypherMachine getCypherMachine() {
return cypherMachine;
}
/**
* @param cypherMachine the cypherMachine to set
*/
public void setCypherMachine(CypherMachine cypherMachine) {
this.cypherMachine = cypherMachine;
}
/**
* @return the encryptedClassType
*/
public Class getEncryptedClassType() {
return encryptedClassType;
}
/**
* @param encryptedClassType the encryptedClassType to set
*/
public void setEncryptedClassType(Class encryptedClassType) {
this.encryptedClassType = encryptedClassType;
}
private Object decryptObject(Object o) {
try {
Method decrypt =
encryptedClassType.getMethod("decrypt", CypherMachine.class);
return decrypt.invoke(o, cypherMachine);
}
catch(Exception e) {
return null;
}
}
private Object encryptObject(Object o) {
try {
Method encrypt =
encryptedClassType.getMethod("encrypt", CypherMachine.class);
return encrypt.invoke(o, cypherMachine);
}
catch(Exception e) {
return null;
}
}
public void ojbAdd(Object anObject) {
super.ojbAdd(this.decryptObject(anObject));
}
public void ojbAddAll(ManageableCollection otherCollection) {
Iterator i = otherCollection.ojbIterator();
while(i.hasNext()) {
this.ojbAdd(i.next());
}
}
public Iterator ojbIterator() {
EncryptableCollectionProxy ecp =
new
Encryptab
Re: storing objects
Hans Novak wrote: Did you read the post from Alessandro ? He wrote something to catch this known problem ... I will try it later. yep, I read it. Sorry I don't have the time to check the source code of this project for performance issues/bottlenecks/"bugs". I checked method #updateCollectionReference(...): Performs an additional DB roundup to get all persisted collection objects and compare these objects with objects of the reference. It compares the objects based on #equals(..) method. So you need a proper equals method implementation. It doesn't use OJB's PersistentField implementation http://db.apache.org/ojb/docu/guides/advanced-technique.html#Change+PersistentField+Class to access the members - you need proper public setter/getter. But generally speaking this method should do the job (as workaround till we fix this in OJB) [For Alessandro] Think this method can be improved (I don't want to criticize you ;-)). Use a report query an query only the PK fields of the collection. Then build the Identity objects and compare against the Identity objects of the current collection to find the deleted objects - No need for proper object.equals(..) method implementation of the persistence capable objects. Use Object value = FieldDescriptor/CollectionDescriptor.getPersistentField().get(source) to read the field value of an persistence capable object. Use PB.getDescriptorRepository() to lookup the current used DescriptorRepository instance. regards, Armin Hans - 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: storing objects
Hi Hans, Hans Novak wrote: Hi, i am not shure, but is ist correct when i have an object, witch is a tree of some other objects (colletions) and i delete a part of the tree and then store the hole object (tree) - in the database the deleted object will also be deleted ? Everything works fine, when i store or update the object, but not when i delete. The deleted part of the object will not be deleted in the database. I can remove it by hand, when i run a remove.object (the part of the tree) and then store the (changed) tree. Is this normal ? It's how OJB currently work. But I agree this is not the behavior a user expects when using a "removal aware" collection and above all the odmg-api implementation detects the removed/orphan objects and delete them. OJB (PB-api) ignore the objects detected by the removal aware collection on delete of the main object. I will have a look at this. regards, Armin Hans - 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: ojb_blank problem
Hi Hans, Hans Novak wrote: Have you got my mail ? I sorry to say NO. If your mail had an attachment try without again (the apache server is very restrict in handling attachments). regards, Armin Hans Armin Waibel schrieb: Hans Novak wrote: Armin Waibel schrieb: Think this is problem caused by xdoclet itself, because the error starts with error: xjavadoc.TokenMgrError: I suppose you need a Java5/6 compatible xdoclet version (xjavadoc). hmmm... where can i get it ? I use under Linux the latest SUN Java SDK with eclipse and the latest ojb_blank, nothing more .. The xdoclet modules are included in OJB (see [db-ojb]/lib directory). The (xdoclet,xjavadoc) issue below seems very similar to yours http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1601 You can try the link below to get a xjavadoc-1.5 snapshot (this may solve your xjavadoc problem): http://prdownloads.sourceforge.net/xdoclet/xjavadoc-1.5-snapshot050611.jar?download This error always pop up when using hsql. Simply ignore it. i use mysql - not hsql (i have try it too, but the same error) It looks like, that the sql file will be executed on the command line with bash interpreter (and not something like "mysql -u whatever -p ...< [sql-file]" ) Running torque/ddlutils can cause some drop-table error logs at the first time run, when tables do not exist (running hsql with in-memory mode this always happens). i understand, but again, i use mysql. There are some things i cant understand: If i run the buildfile with target "create-db" it will try to create the db and creates succsessfull the SQL Files - BUT forgets some XML Files to create/change (sometimes). I must every time run first the target "build" and then the "create-db" - althought create-db depends on build ... !? In other words: if i run the target "create-db" some times, with existing xml Files, these files will not be overwritten, only when i run the "build" target. Ok, this ist not a big problem, but i dont know why. hmm, sounds like an override issue. Maybe only the "build" task remove the old files completely and replace it by new ones. The other thing (and for me a much more problem) the ant task forget foreign keys of the classes. I think, there is somewehre a problem in the java File - NOT in ojb / builder, but i dont get any error, something like "a field ist not persistent" or similar. My Java code is very big - i am desperating to find the error in the code, if the ant task dont help me Hans p.s. is there a chance to write in german ? (english is very hard to me) No sweat! Schreib einfach direkt an mich. regards Armin - 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: Error with nested class
Hi Robert,
Robert Giddings wrote:
Hi Armin,
Here is the code of the class and inner class in question.
Rob
package com.netcase.netspat.recordSystem.bo;
import com.netcase.bo.BaseObject;
public class Country extends BaseObject {
...
/*
* Nested
*/
/**
* @ojb.nested
* @ojb.modify-nested name="id"
*primarykey=""
*/
private CountryDateSet publicationDates;
...
/*
* Constructors
*/
public Country() {
super();
}
...
public class CountryDateSet extends BaseObject {
/*
* Fields
*/
OJB can't instantiate a non-static inner class. Declare CountryDateSet
as static inner class - this should solve the problem (this is only
possible if CountryDateSet doesn't use access to outer class Country
members - I don't check this).
regards,
Armin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error with nested class
Hi Robert, could you please post the mapping and java source for class Country (I expect that this is the class which declares field 'publicationDates'?) too. regards, Armin Robert Giddings wrote: Hi, Can anyone tell me why I get this runtime exception when using OJB as the inner class is neither abstract nor an interface and has a no parameter default constructor. The inner class does extend an abstract class, but that doesn't seem to be a problem. Thanks, Robert Giddings Caused by: org.apache.ojb.broker.metadata.MetadataException: Can't create nested object of type 'class com.netcase.netspat.recordSystem.bo.Country$CountryDateSe t' for field 'publicationDates' at org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectImpl. set(Unknown Source) at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.buildOrRefresh Object(Unknown Source) at org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl.readObjectFrom (Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(U nknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.next(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery( Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery( Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery( Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery (Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB yQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB yQuery(Unknown Source) at com.netcase.database.DAOService.getObjectsByType(DAOService.java:41) ... 21 more Caused by: java.lang.InstantiationException: com.netcase.netspat.recordSystem.bo .Country$CountryDateSet at java.lang.Class.newInstance0(Class.java:335) at java.lang.Class.newInstance(Class.java:303) at org.apache.ojb.broker.util.ClassHelper.newInstance(Unknown Source) ... 33 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: n:m mapping problem
Hi, your mapping seems ok. Sounds like a bug in OJB. I tried to reproduce your problem without success (using latest version of OJB from SVN OJB_1_0_RELEASE branch) - never get a NPE. I use the mapping from the m:n example (with Person and Project) and do: oid = broker.serviceIdentity().buildIdentity(Person.class, new Integer(1)); person = (Person) broker.getObjectByIdentity(oid); No NPE. How can I reproduce your problem? regards, Armin Truong Nguyen Huy wrote: Hi all, I have a problem when using m:n mapping. I will describe it below. I just implement a tutorial in this link http://db.apache.org/ojb/docu/guides/basic-technique.html#Support+for+Non-Decomposed+m%3An+Mappings There are three table: PERSON, PROJECT, PROJECT_PERSON. PROJECT_PERSON is the connector standing for m:n relation between PROJECT and PERSON. PROJECT(id,name) PERSON(id,name) PROJECT_PERSON(project_id, person_id) The mapping file as below: table="person" jdbc-type="INTEGER" primarykey="true" autoincrement="true" /> element-class-ref="vn.com.tma.testOJB.Project" auto-retrieve="true" auto-update="true" indirection-table="PROJECT_PERSON" table="project" jdbc-type="INTEGER" primarykey="true" autoincrement="true" /> element-class-ref="vn.com.tma.testOJB.Person" auto-retrieve="true" auto-update="false" indirection-table="PROJECT_PERSON" When I run these codes, it has error: PersistenceBroker broker = PersistenceBrokerFactory.defaultPersistenceBroker(); Identity oid = broker.serviceIdentity().buildIdentity(Person.class, new Integer(1)); Person person = (Person) broker.getObjectByIdentity(oid); The error is caused by the third line. This is the exception stack: Exception in thread "main" org.apache.ojb.broker.PersistenceBrokerException: java.lang.NullPointerException at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.doRetrieveCollection(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.doRetrieveCollections(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByIdentity(Unknown Source) at vn.com.tma.main.Run.main(Run.java:41) Caused by: java.lang.NullPointerException at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.associateBatched(Unknown Source) at org.apache.ojb.broker.accesslayer.MtoNCollectionPrefetcher.prefetchRelationship(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) ... 11 more But if I change auto-archive to "false" in arbitrary one of two class-descriptor, there is no error anymore. But it still causes the same error when I use method "broker.retrieveAllReferences()" on an instance of the rest class-descriptor. Only when I change auto-archive of both class-descriptor to "false", the error is omitted. Can anyone explain why and help me resolve the problem when using auto-archive="true" on both class-descriptor? Thank you very for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ojb_blank problem
Hans Novak wrote: Armin Waibel schrieb: Think this is problem caused by xdoclet itself, because the error starts with error: xjavadoc.TokenMgrError: I suppose you need a Java5/6 compatible xdoclet version (xjavadoc). hmmm... where can i get it ? I use under Linux the latest SUN Java SDK with eclipse and the latest ojb_blank, nothing more .. The xdoclet modules are included in OJB (see [db-ojb]/lib directory). The (xdoclet,xjavadoc) issue below seems very similar to yours http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1601 You can try the link below to get a xjavadoc-1.5 snapshot (this may solve your xjavadoc problem): http://prdownloads.sourceforge.net/xdoclet/xjavadoc-1.5-snapshot050611.jar?download This error always pop up when using hsql. Simply ignore it. i use mysql - not hsql (i have try it too, but the same error) It looks like, that the sql file will be executed on the command line with bash interpreter (and not something like "mysql -u whatever -p ...< [sql-file]" ) Running torque/ddlutils can cause some drop-table error logs at the first time run, when tables do not exist (running hsql with in-memory mode this always happens). i understand, but again, i use mysql. There are some things i cant understand: If i run the buildfile with target "create-db" it will try to create the db and creates succsessfull the SQL Files - BUT forgets some XML Files to create/change (sometimes). I must every time run first the target "build" and then the "create-db" - althought create-db depends on build ... !? In other words: if i run the target "create-db" some times, with existing xml Files, these files will not be overwritten, only when i run the "build" target. Ok, this ist not a big problem, but i dont know why. hmm, sounds like an override issue. Maybe only the "build" task remove the old files completely and replace it by new ones. The other thing (and for me a much more problem) the ant task forget foreign keys of the classes. I think, there is somewehre a problem in the java File - NOT in ojb / builder, but i dont get any error, something like "a field ist not persistent" or similar. My Java code is very big - i am desperating to find the error in the code, if the ant task dont help me Hans p.s. is there a chance to write in german ? (english is very hard to me) No sweat! Schreib einfach direkt an mich. regards Armin - 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: ojb_blank problem
Hi Hans,
sorry for the late reply.
Hans Novak wrote:
Hi,
i need help to run the ojb_blank projekt (i try with mysql & hsql, same
errors)
If i configure it like the tutorial says, i get in eclipse some errors:
first, i get a lot of errors like this:
[ojbdoclet] 2007-08-29 13:35:28,017 [main] INFO
xdoclet.XDocletMain.start - Running
[ojbdoclet] Error parsing File
/home/hnovak/eclipse-workspace/osfaktura/src/java/AfterBuyImport.java:Lexical
error: xjavadoc.TokenMgrError: Lexical error at line 11, column 1.
Encountered: "@" (64), after : ""
[ojbdoclet] Error parsing File
/home/hnovak/eclipse-workspace/osfaktura/src/java/de/repcom/osfaktura/core/partner/Partner.java:Encountered
"<" at line 255, column 22.
[ojbdoclet] Was expecting one of:
[ojbdoclet] ...
[ojbdoclet] "[" ...
[ojbdoclet] "." ...
[ojbdoclet] "(" ...
at the line 255 in Partner.java is Collection col ...
It sounds like, that it can recognize the Java 5/6 notation.
The "project-schema.xml/sql" is not written correctly. On some classes
it miss the foreign-key statements. If i cut the java 5/6 notation out
from Collection in the java classes, then it writes it correctly with
foreign-key statements.
Think this is problem caused by xdoclet itself, because the error starts
with
error: xjavadoc.TokenMgrError:
I suppose you need a Java5/6 compatible xdoclet version (xjavadoc).
Then i get these errors:
shutdown-check:
append-shutdown-sql:
[echo]
[echo] Executing the create-db.sql script ...
[echo] [sql] Executing resource:
/home/hnovak/eclipse-workspace/osfaktura/build/database/create-db.sql
[sql] Failed to execute: ECHO Not implemented [sql]
java.sql.SQLException: Unexpected token: ECHO in statement [ ECHO]
[sql] 1 of 2 SQL statements executed successfully
This error always pop up when using hsql. Simply ignore it.
insert-sql:
shutdown-check:
add-shutdown-sql-file:
[torque-sql-exec] Our new url -> jdbc:hsqldb:build/database/ojb_blank
[torque-sql-exec] Executing file:
/home/hnovak/eclipse-workspace/osfaktura/build/database/project-schema.sql
[torque-sql-exec] Failed to execute: drop table PARTNER if exists; ...
(SNIP REST OUT) ...
[torque-sql-exec] Executing file:
/home/hnovak/eclipse-workspace/osfaktura/build/database/ojbcore-schema.sql
[torque-sql-exec] Executing file:
/home/hnovak/eclipse-workspace/osfaktura/build/database/shutdown.sql
[torque-sql-exec] 2 of 3 SQL statements executed successfully
BUILD SUCCESSFUL
Total time: 6 seconds
If i do a: "mysql db <./project-schema.sql" (and the other two sql
scripts) it works fine (except for the "foreign key" statements, i wrote
above)
Running torque/ddlutils can cause some drop-table error logs at the
first time run, when tables do not exist (running hsql with in-memory
mode this always happens).
regards,
Armin
Hans
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: what's with OJB Project?
Hi Sergey, Manukyan, Sergey wrote: Folks, It has been a while since last release of 1.0.4. I have been a user of ojb since 1.0.2... for about 4 years... but going forward concerns me. With no new releases I would like to ask how does the perspective looks for this project? Well, it depends on the community. Currently it seems that only a few people are able to (interested in) spend time for OJB. I will continue my work on OJB. Is work currently being done? Yep! Will check in some improvements for OJB's xdoclet module within the next few days (docs and license notes are up to date - did this a few ago) and then build an unofficial 1.5rc1 to give user the ability to test the upcoming 1.0.5 release before official release. Why such a big gap in releases? Lack of manpower (nobody wants to do the administrative stuff ;-)). Are there still plans to ship 1.1? I started work on trunk/1.1?/2.0? and locally I have a lot of files to check in (1.0.x backports + new stuff) and many ideas in mind. But without support of other developer it's hard to realize. regards, Armin Regards, -Sergey ** ** LEGAL DISCLAIMER ** ** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. - 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: Getting repository information
Hi Lasse,
Lambrecht, Lasse (Allianz Deutschland AG) wrote:
Hello everybody,
I'm trying to get some of the information stored in the repository
files (of my o/r mapping). So far I tried something like this to get
the "translation" from the Java name of an attribute to the DB2
column name - which works fine:
DescriptorRepository lRepository =
ojbBrokerRef.getDescriptorRepository(); try { ClassDescriptor lClass
= lRepository.getDescriptorFor(persistenteKlasse); FieldDescriptor
lField = lClass.getFieldDescriptorByName(feldname); lResult =
lField.getColumnName(); } catch (ClassNotPersistenceCapableException
e) { }
Now two questions: a) is there a way to do the opposite? I have a DB2
table/column name and want to get the Java name. Sure, I can iterate
through all ClassDescriptors, but that seems not the perfect solution
(my repository-XML is close to 1 MB).
Sorry, OJB doesn't provide such specific "reverse"-methods! If this
happens more then a few times and performance is significant, I
recommend to map table-name/ClassDescriptor once on startup of the
application (if different repository profiles are used you have to take
care of this too -
http://db.apache.org/ojb/docu/guides/metadata.html#Object+metadata+profiles).
b) how can I find a field, if I
don't know, in which ClassDescriptor the field is located? I only
have a field name in some rare situations. The fieldname is unique.
The only way I see is to, again, iterate through all
ClassDescriptors.
yep! Or again map this by your own on startup of the application.
I would recommend to write a simple test to check the time period for
CLD-iteration and then decide which way to go.
regards,
Armin
Regards Lasse Lambrecht
_
Allianz Deutschland AG Vorsitzender des Aufsichtsrats: Michael
Diekmann. Vorstand: Dr. Gerhard Rupprecht, Vorsitzender; Hansjörg
Cramer, Dr. Karl-Hermann Lowe, Dr. Christof Mascher, Thomas Pleines,
Dr. Ulrich Rumm, Ulrich Schumacher, Dr. Maximilian Zimmerer. Für
Umsatzsteuerzwecke: USt-ID-Nr.: DE 814 580 981 ;
Versicherungsbeiträge sind umsatzsteuerfrei. Sitz der Gesellschaft:
München Registergericht: München HRB 158878
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding metadata handling in ojb 1.0.4
Hi Bernd,
Längerich, Bernd wrote:
Hi,
I am trying to find some information regarding metadata merging in
the following scenario:
We have a base application with some classes, db tables and a
repository_user.xml that describes the mapping. Lets say we have a
base class BasePersistentClassA and some classes that are based which
are included as extent classes in the xml file. This application is
running.
No we develop an optional plugin with a class PluginPersistentClassB
that is based on BasePersistentClassA of the application. I can now
write an additional repository.xml and merge it with:
MetadataManager mm = MetadataManager.getInstance();
DescriptorRepository dr =
mm.readDescriptorRepository("my/additional/plugin_repository.xml");
mm.mergeDescriptorRepository(dr);
However I am failing to get the correct contents regarding the
extent-class definitions of the base class. I tried to include the
following to plugin_repository.xml:
Since ClassB is an "extent" of ClassA the merge of the repositories
isn't enough. The merge method is intended to merge/add new classes
without dependencies to already registered classes.
You could try to use the ClassDescriptor.addExtent(...) method to
register a new "extent":
MetadataManager mm = MetadataManager.getInstance();
DescriptorRepository dr =
mm.readDescriptorRepository("my/additional/plugin_repository.xml");
mm.mergeDescriptorRepository(dr);
//then lookup the repository
DescriptorRepository repo = mm.getRepository();
// lookup the CLD of ClassA
ClassDescriptor cldA = repo.getDescriptorFor(ClassA.class);
// add the new extent
cldA.addExtent(ClassB);
I never tried this ;-)
regards,
Armin
Something is strange, as the following code fragment does not delete
anything at the first broker.deleteByQuery() and fails at the second
one:
Criteria crit = new Criteria();
crit.addNotEqualTo("ojbConcreteClass",BaseApplicationClassX.class.getName());
Query q = QueryFactory.newQuery(Transaction.class,crit);
broker.deleteByQuery(q);
// SELECT DISTINCT ACC_TAID FROM ACC_TA ReportQueryByCriteria
subquery = new ReportQueryByCriteria(BasePersistentClassA
.class,null); subquery.setAttributes(new String[] { "id" });
subquery.setDistinct(true);
Criteria crit = new Criteria(); crit.addNotIn("externalID",subquery);
Query q = QueryFactory.newQuery(Another.class,crit);
broker.deleteByQuery(q);
It seems that the extent definitions from dr are not merged and even
corrupt the existing definitions of the application, as trying to
access all classes from the database results in an
NullPointerException:
2007.07.26 17:40:33,375
[0/ServiceRequestDispatcher-P=3/T=7-running:1/1/1] INFO cleardb:
start java.lang.NullPointerException at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias.hashCode(Unknown
Source) at java.util.HashMap.hash(Unknown Source) at
java.util.HashMap.put(Unknown Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.splitCriteria(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlSelectStatement.(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.getSubQuerySQL(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendSubQuery(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendParameter(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendInCriteria(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendCriteria(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendSQLClause(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.asSQLStatement(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendClause(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendWhereClause(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlDeleteByQuery.buildStatement(Unknown
Source) at
org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.getStatement(Unknown
Source) at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeDelete(Unknown
Source) at
org.apache.ojb.broker.core.PersistenceBrokerImpl.deleteByQuery(Unknown
Source) at
org.apache.ojb.broker.core.PersistenceBrokerImpl.deleteByQuery(Unknown
Source) at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.deleteByQuery(Unknown
Source) at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.deleteByQuery(Unknown
Source) [...]
If I include the table="" part, I get the NullPointerException at:
so it seems that the existing class definition is not merged with the
additional data but overwritten.
Ommiting the extent-class-definitions from the additional xml file, I
can access all classes of the base application, but not of the
plugin. As we have several plugins, we dont want any dependencies
from the base application to the plugins.
Any hints are appreciated
Re: QueryBySQL
Hi Krupa,
krupa wrote:
Hi All,
I have several SQLs already written.
I want to use QueryBySQL to use the existing SQLs. The problem I am facing
is how do I map the result set of these queries to my java classes,
especially if I have a result set that includes fields from 3 tables
then how do I map this in the reposity.xml file?
Using an existing sql-string spanning several tables (persistence
capable classes) can't be mapped to a java class by OJB, but you can use
a report query which returns each result set row as an object array and
map these array by your own:
Query query = QueryFactory.newQuery(null, sql);
Iterator it = broker.getReportQueryIteratorByQuery(query);
while(it.hasNext())
{
Object o = it.next();
System.out.println("result: " + ArrayUtils.toString(o));
}
NOTE: There is a bug in OJB versions <=1.0.4 if you try to perform such
a report query. The latest version from SVN (OJB_1_0_RELEASE branch!!)
contains a bug fix.
regards,
Armin
Please help me with this.
here is an example of my SQL statement.
select A1.field1, A1.field2, A1.field3,A2.field1,
A2.field2,A2.field3,A2.field4,
A3.field1 as tmp1, A3.field2 as tmphdr2
from (((Table1
left outer join table2 on field1= field2)
left outer join table2 A2 on field2 = A2.field2)
left outer join table2 A3 on field5= A3.field2)
left outer join table2 A4 on field6 = A3.field2
where field1= 12
and field8 = ''A''
order by field9
;
Thanks,
Krupa
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cancel proxying for custom request
Hi, Maxim Kuleshov wrote: Hello! Most of the times I prefer to use proxying of collections, but in contrast, for certain requests I need no proxying at all. Is there any method to create such custom query? Sorry no. The proxy setting are global and changes will affect all other threads/user too. The thing that comes to my mind is to use different repository mapping profiles (one with proxy enabled, other with proxy settings disabled). Then load the none proxy mapping profile, lookup the PB instance, perform the query, close the PB, reset the default mapping profile. http://db.apache.org/ojb/docu/guides/metadata.html#Per+thread+metadata+changes http://db.apache.org/ojb/docu/guides/metadata.html#Object+metadata+profiles regards, Armin Thanks in advance. - 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: Proxy null poiter exception with bad references
Hi Martin,
Martin Heyer wrote:
Hello Ojb-Users.
I have a Cocoon + OJB installation running. For performance reasons
there is a dynamic Proxy configured with class B. For example let's
have two classes A and B:
Class A: (has no proxy) - uid - link -> points to uid of class B - B
(foreign key, holds the instance of B associated with link)
Class B: (has a proxy) - uid - data
Everything works fine without the proxy. But when proxy is turned on
and A points to an ID that has no B in the DB, it throws a NPE:
... Caused by: org.apache.ojb.broker.PersistenceBrokerException:
Error invoking method getIndirectionHandler at
org.apache.ojb.broker.core.proxy.AbstractIndirectionHandler.invoke(AbstractIndirectionHandler.java:363)
at $Proxy29.getIndirectionHandler(Unknown Source) ... 61 more Caused
by: java.lang.NullPointerException at
org.apache.ojb.broker.core.proxy.AbstractIndirectionHandler.invoke(AbstractIndirectionHandler.java:347)
... 62 more
Is there a way to catch this? I can load A so it has a proxy instance
of B associated with it. ATM there is no way for me to know if the
proxy will find a real object of B. When I access this reference, it
crashes..
This should be fixed in SVN:
http://www.mail-archive.com/ojb-dev%40db.apache.org/msg03485.html
The only "workaround" I know is to patch method
AbstractIndirectionHandler.invoke(Object proxy, Method method, Object[]
args)
replace:
return method.invoke(subject, args);
with:
if("toString".equals(methodName) && subject == null)
{
return null;
}
if(subject == null)
{
log.warn("Real object of this proxy object doesn't exist, all
method will return 'null': " + getIdentity());
return null;
}
else
{
return method.invoke(subject, args);
}
OR use your own IndirectionHandler implementation class e.g.
public class IndirectionHandlerCGLIBPatchedImpl extends
IndirectionHandlerCGLIBImpl
{
...
}
and override the invoke-method in same way described above and declare
it in OJB.properties file (IndirectionHandlerClass=...). But in this
case you have use the reflection-API to get access to a private member
"_realSubject" in AbstractIndirectionHandler.
regards,
Armin
I really would appreciate help,
Martin
-
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: per-class cache
Hi, Maxim Kuleshov wrote: Hello! If I use per-class cache feature, will cache instance be created for every distinct class? Guess, it's wasteful to have different caches sharing exactly same behavior. That special cache will be used to store almost-static DB data. How could I implement this? You can declare different caches for each class if needed (override the global defined cache on jdbc-connection-descriptor level) http://db.apache.org/ojb/docu/guides/objectcache.html#How+to+declare+and+change+the+used+ObjectCache+implementation Dependent on the used cache implementation the specified attributes should take effect only for objects of the class. regards, Armin - 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: Problem with OJB 1.0.3 and ORACLE 10
Hi Michele,
Fabbri Michele wrote:
Hello everybody,
I have a problem with an application using OJB and Oracle 10, the same
application work fine with Oracle 9.
OJB doesn't connect to the DBMS, I activate the log and I obtain the log
under, have you any suggestion?
I think it's a typo:
> [EMAIL PROTECTED]
> jcd-alias=PEOPLE_DB
and
> Obtain broker from pool, used PBKey is org.apache.ojb.broker.PBKey:
> jcdAlias=PEOPLEDB, user=null, password=null
could this be the case?
regards,
Armin
Thank a lot
Michele Fabbri
2007-05-10 18:05:35,020 [http-8080-Processor24] DEBUG
org.apache.ojb.broker.metadata.ConnectionRepository.addDescriptor(Connec
tionRepository.java:129)
New descriptor was added:
[EMAIL PROTECTED]
jcd-alias=PEOPLE_DB
default-connection=true
dbms=Oracle9i
jdbc-level=2.0
driver=oracle.jdbc.driver.OracleDriver
protocol=jdbc
sub-protocol=oracle
db-alias=thin:@10.101.101.209:1521:reference
user=fedb
password=*
eager-release=false
ConnectionPoolDescriptor={whenExhaustedAction=2, maxIdle=10,
maxActive=1000, maxWait=5000, removeAbandoned=false,
numTestsPerEvictionRun=10, testWhileIdle=false,
minEvictableIdleTimeMillis=60, testOnReturn=false,
logAbandoned=false, removeAbandonedTimeout=300,
timeBetweenEvictionRunsMillis=5000, testOnBorrow=true}
batchMode=false
useAutoCommit=AUTO_COMMIT_SET_TRUE_AND_TEMPORARY_FALSE
ignoreAutoCommitExceptions=false
[EMAIL PROTECTED]
cb0[
sequenceManagerClass=class
org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl
Properties={autoNaming=true}
]
]
2007-05-10 18:05:35,021 [http-8080-Processor24] INFO
org.apache.ojb.broker.metadata.RepositoryPersistor.readConnectionReposit
ory(RepositoryPersistor.java:203)
Read connection repository took 91 ms
2007-05-10 18:05:35,050 [http-8080-Processor24] INFO
org.apache.ojb.broker.metadata.ConnectionRepository.getDescriptor(Connec
tionRepository.java:73)
Could not find org.apache.ojb.broker.metadata.JdbcConnectionDescriptor
for PBKey org.apache.ojb.broker.PBKey: jcdAlias=PEOPLEDB, user=null,
password=null
2007-05-10 18:05:35,055 [http-8080-Processor24] DEBUG
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl.createPer
sistenceBroker(PersistenceBrokerFactoryDefaultImpl.java:86)
Obtain broker from pool, used PBKey is org.apache.ojb.broker.PBKey:
jcdAlias=PEOPLEDB, user=null, password=null
The repository xml file is:
]>
jcd-alias="PEOPLE_DB"
default-connection="true"
platform="Oracle9i"
jdbc-level="2.0"
driver="oracle.jdbc.driver.OracleDriver"
protocol="jdbc"
subprotocol="oracle"
dbalias="thin:@10.101.101.209:1521:reference"
username="fedb"
password="reference"
useAutoCommit="1"
maxWait="2">
whenExhaustedAction="2"
testOnBorrow="true"
timeBetweenEvictionRunsMillis="5000"/>
jdbc-type="BIGINT"
primarykey="true"
conversion="it.people.core.persistence.converters.sql.LongConverter"
autoincrement="true"/>
name="persistentData"
class-ref="it.people.process.data.PplPersistentData"
auto-retrieve="true" auto-delete="false"
auto-update="false" >
Re: Using getReportQueryIteratorByQuery
Ali HACHAMI wrote:
Hi Armin,
I did the test using 1.0.4.
I compared the sources from SVN with 1.0.4 and didn't found (much)
differences in column handling via report query (SqlQueryStatement,
ReportQueryByCriteria, ReportQueryRsIterator). So I would expect the
same issue in latest version from SVN too.
Is it possible for you to run your test against the latest version from
SVN (OJB_1_0_RELEASE branch!) or could you post detailed information to
reproduce the test (test sources, test classes + mapping (only the
mandatory columns/fields))?
regards,
Armin
Best regards,
Ali
On 5/11/07, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Ali,
Ali HACHAMI wrote:
> Hi Armin,
>
>
> I tried to fix the problem by renaming the class's attributes, but the
> problem is still there. In conclusion the problem happen when the
columns
> have the same name in the tables (not in the classes).
>
In my test the java field name ("name") + column name ("NAME_") are the
same in both classes/tables.
Did you tried to fix the issue using 1.0.4 or did you tried the latest
version from SVN (OJB_1_0_RELEASE branch!)?
regards,
Armin
>
>
> Best regards,
>
> Ali
>
>
> On 5/5/07, Armin Waibel <[EMAIL PROTECTED]> wrote:
>>
>> Hi Ali,
>>
>> sorry for the late reply. Last week I had a DSL malfunction caused by
my
>> Internet provider. It seems to be fixed (works again for 20 hours),
but
>> it could happen that I'm out of business again.
>>
>>
>> Ali HACHAMI wrote:
>> > Hi,
>> > I'm using getReportQueryIteratorByQuery and I want to select columns
>> that
>> > have the same name but are not present in my criteria :
>> >
>> >
>> > Criteria crit1 = new Criteria();
>> > crit1.addEqualTo("id", new Integer(1));
>> >
>> > q = QueryFactory.newReportQuery(Container.class, crit1);
>> >
>> > String[] cols = { id, "name", "refOtherClass.name "};
>> > q.setAttributes(cls);
>> >
>> > The pb is that I'm getting the same value for the columns "name" and
"
>> > refOtherClass.name".
>> >
>> > Any help?
>>
>> I try to reproduce your problem and setup a similar test with class
>> Author and Publisher (1:1 relation Author-Publisher):
>>
>> Query q = QueryFactory.newReportQuery(
>> Author.class, new String[]{"id", "name", "publisher.name"}, null,
true);
>> Iterator result = broker.getReportQueryIteratorByQuery(q);
>> while(result.hasNext())
>> {
>> System.out.println(ArrayUtils.toString(result.next()));
>> }
>>
>> Result:
>> {21,author_1_testA_1178367631953_,publisher_testA_1178367631953_}
>> {22,author_2_testA_1178367631953_,publisher_testA_1178367631953_}
>> {23,author_3_testA_1178367631953_,publisher_testA_1178367631953_}
>> {24,author_4_testA_1178367631953_,publisher_testA_1178367631953_}
>>
>> As you can see this works with latest version from SVN
(OJB_1_0_RELEASE
>> branch!). I don't try this test with OJB 1.0.4. So if it's a bug in
>> 1.0.4, it seems to be fixed in the next upcoming version of OJB.
>>
>> If your problem still happens with latest from SVN, please post the
>> mapping for class Container and the referenced class.
>>
>> regards,
>> Armin
>>
>>
>> > Thanks in advance,
>> >
>> > Ali
>> >
>>
>> -
>> 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 getReportQueryIteratorByQuery
Hi Ali,
Ali HACHAMI wrote:
Hi Armin,
I tried to fix the problem by renaming the class's attributes, but the
problem is still there. In conclusion the problem happen when the columns
have the same name in the tables (not in the classes).
In my test the java field name ("name") + column name ("NAME_") are the
same in both classes/tables.
Did you tried to fix the issue using 1.0.4 or did you tried the latest
version from SVN (OJB_1_0_RELEASE branch!)?
regards,
Armin
Best regards,
Ali
On 5/5/07, Armin Waibel <[EMAIL PROTECTED]> wrote:
Hi Ali,
sorry for the late reply. Last week I had a DSL malfunction caused by my
Internet provider. It seems to be fixed (works again for 20 hours), but
it could happen that I'm out of business again.
Ali HACHAMI wrote:
> Hi,
> I'm using getReportQueryIteratorByQuery and I want to select columns
that
> have the same name but are not present in my criteria :
>
>
> Criteria crit1 = new Criteria();
> crit1.addEqualTo("id", new Integer(1));
>
> q = QueryFactory.newReportQuery(Container.class, crit1);
>
> String[] cols = { id, "name", "refOtherClass.name "};
> q.setAttributes(cls);
>
> The pb is that I'm getting the same value for the columns "name" and "
> refOtherClass.name".
>
> Any help?
I try to reproduce your problem and setup a similar test with class
Author and Publisher (1:1 relation Author-Publisher):
Query q = QueryFactory.newReportQuery(
Author.class, new String[]{"id", "name", "publisher.name"}, null, true);
Iterator result = broker.getReportQueryIteratorByQuery(q);
while(result.hasNext())
{
System.out.println(ArrayUtils.toString(result.next()));
}
Result:
{21,author_1_testA_1178367631953_,publisher_testA_1178367631953_}
{22,author_2_testA_1178367631953_,publisher_testA_1178367631953_}
{23,author_3_testA_1178367631953_,publisher_testA_1178367631953_}
{24,author_4_testA_1178367631953_,publisher_testA_1178367631953_}
As you can see this works with latest version from SVN (OJB_1_0_RELEASE
branch!). I don't try this test with OJB 1.0.4. So if it's a bug in
1.0.4, it seems to be fixed in the next upcoming version of OJB.
If your problem still happens with latest from SVN, please post the
mapping for class Container and the referenced class.
regards,
Armin
> Thanks in advance,
>
> Ali
>
-
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: java.net.SocketException: Connection reset
Hi Abid, Abid Hussain wrote: Hello everybody, I'm using OJB in my web applicatin now for more than one year, and it did really fine. But since some time an exception occurs which I can't figure out. Obviously the connection to the backend was reset. May it be the case that the db connection timed out? Anybody got an idea what I can do about this? I found this issue in jira but I'm not sure if it's the same case as mine: http://issues.apache.org/jira/browse/OJB-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel It could be a similar connection time out issue. In this case try to - enable automatic reconnect of timed out connections in the jdbc-driver - or use a validation query - or enable automatic cleanup of idle connections in the connection pool to prevent timed out connections. If the exception only occur under heavy load it could be a concurrency issue: http://archives.postgresql.org/pgsql-jdbc/2006-09/msg1.php This could happen when different threads at the same time operate on the same PersistenceBroker instance. regards, Armin Best regards, Abid Here's the stack trace: ERROR: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] * SQLException during execution of sql-statement: * sql statement was 'SELECT A0.Id,A0.modul_Name,A0.LP,A0.Zuordnung,A0.Ziele,A0.Inhalte,A0.Literatur,A0.Voraussetzung,A0.Modulpruefung,A0.Selbststudium,A0.Form_Teilnahme,A0.Sprache,A0.Aufwand_Gesamt,A0.Dauer,A0.Haeufigkeit,A0.Sonst_Verantwortliche FROM Modul_2 A0 WHERE A0.Id = ?' * Exception message is [An I/O error occured while sending to the backend.] * Vendor error code [0] * SQL state code [08006] * Target class is 'modulverwaltung.beans.Module_2' * PK of the target object is [id] * The root stack trace is --> * java.net.SocketException: Connection reset at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at org.postgresql.core.PGStream.flush(PGStream.java:494) at org.postgresql.core.v3.QueryExecutorImpl.sendSync(QueryExecutorImpl.java:631) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:174) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:389) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:330) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:240) at com.p6spy.engine.logging.P6LogPreparedStatement.executeQuery(P6LogPreparedStatement.java:172) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.materializeObject(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getPlainDBObject(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByIdentity(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(Unknown Source) at modulverwaltung.persistence.Module_2DAO.findByPrimaryKey(Module_2DAO.java:73) at modulverwaltung.action.ShowModule.performAction(ShowModule.java:32) at modulverwaltung.controller.Controller.doGet(Controller.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.la
Re: internationalization with OJB
Hi Ozkan,
sorry for the late reply. Last week I a had DSL malfunction caused by my
Internet provider. It seems to be fixed (works again for 20 hours), but
it could happen that I'm out of business again.
zkn wrote:
Is internationalization possible with OJB?
yep! why not?
I'm not sure if the question is correct. I have to create a web
application that has to support multiple languages. I'm going to use
resource files for the messages.
But are there any best practices for making databases with multi
language support and does OJB support one?
(nearly) All best practices of internationalization via databases should
also be possible with OJB.
A popular way (don't know if this is the best way to do it ;-)) is to
use a language identifier in the classes with multiple language support.
For example, class ProductGroup need support for multiple languages in
field 'String name'. Add a INTEGER column "name_id" in table
PRODUCT_GROUP and use a FieldConversion
http://db.apache.org/ojb/docu/guides/jdbc-types.html#The+Solution
in the mapping of field 'name' to transform the column 'name_id' to the
language specific java-field 'name' in class ProductGroup.
Mapping ProductGroup:
...
public static class LanguageConversion implements FieldConversion
{
public Object javaToSql(Object source) throws ConversionException
{
return Language.getId((String) source, User.getLanguage())
}
public Object sqlToJava(Object source) throws ConversionException
{
return Language.getName((Integer) source, User.getLanguage())
}
}
In class Language the mapping of language identity to language string
and vice versa is done. In class User the locale of the current user is
managed.
Hope this simplified example can give you an impetus.
regards,
Armin
Thanks,
Ozkan
-
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: In criteria in PersistenceBroker.getCount(query)
Hi Tadeus,
Tadas Garsva wrote:
Hi,
It seems to me that inCririteria is ignored if I use it in query to get
number of elements. For example:
Query q=QueryFactory.newQuery(clazz,criteria,true);
int n=getBroker().getCount(q);
where criteria has a inCriteria
Because of failing details how your inCriteria look like I setup a
complex test with an inCriteria to reproduce your problem.
I use the latest version of OJB from SVN (OJB_1_0_RELEASE branch!).
Class Project and Person use a m:n relation:
Criteria crit_in = new Criteria().addLike("firstname", "tom")
.addOrCriteria(new Criteria().addLike("firstname", "john"));
Query in_query = QueryFactory.newReportQuery(Person.class, new
String[]{"id"}, crit_in, true);
Criteria crit = new Criteria().addLike("title",
name).addIn("persons.id", in_query);
QueryByCriteria q = QueryFactory.newQuery(Project.class, crit);
int count = broker.getCount(q);
The generated sql:
SELECT count(*) FROM PROJECT A0 INNER JOIN PERSON_PROJECT A1 ON
A0.ID=A1.PROJECT_ID INNER JOIN PERSON A2 ON A1.PERSON_ID=A2.ID WHERE
(A0.TITLE LIKE '_testCountWithInCriteria_1178384142125_') AND A2.ID IN
(SELECT DISTINCT B0.ID FROM PERSON B0 WHERE B0.FIRSTNAME LIKE 'tom' OR
(B0.FIRSTNAME LIKE 'john'))
This works for me! So if possible please try the SVN version.
regards,
Armin
Best regards,
Tadeus Garsva
-
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: anonymous keys and PK in 1.0.4
Hi Sergey, sorry for the late reply. Last week I a had DSL malfunction caused by my Internet provider. It seems to be fixed (works again for 20 hours), but it could happen that I'm out of business again. > > PersistentBroker.delete(new > AmortizedToolingSchedulePO(amortizedToolingSchedule, requisition)) > Think this has to do with implementation of "anonymous keys" http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do The new created AmortizedToolingSchedulePO object doesn't have any mapped anonymous keys in OJB. regards, Armin Manukyan, Sergey wrote: Folks, Just stumbled on the issue with using anonymous keys which make a compound PK of the class. So I have a class that has two references, and using PersistentBroker.delete(new AmortizedToolingSchedulePO(amortizedToolingSchedule, requisition)) It gives me error: [11:20:38,160] ERROR (PersistenceBrokerImpl) - Cannot delete object without valid PKs. All references are valid objects... PK are anponymous... so what is wrong? Thank you in advance, -Sergey ** ** LEGAL DISCLAIMER ** ** This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this E-mail message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using getReportQueryIteratorByQuery
Hi Ali,
sorry for the late reply. Last week I had a DSL malfunction caused by my
Internet provider. It seems to be fixed (works again for 20 hours), but
it could happen that I'm out of business again.
Ali HACHAMI wrote:
Hi,
I'm using getReportQueryIteratorByQuery and I want to select columns that
have the same name but are not present in my criteria :
Criteria crit1 = new Criteria();
crit1.addEqualTo("id", new Integer(1));
q = QueryFactory.newReportQuery(Container.class, crit1);
String[] cols = { id, "name", "refOtherClass.name "};
q.setAttributes(cls);
The pb is that I'm getting the same value for the columns "name" and "
refOtherClass.name".
Any help?
I try to reproduce your problem and setup a similar test with class
Author and Publisher (1:1 relation Author-Publisher):
Query q = QueryFactory.newReportQuery(
Author.class, new String[]{"id", "name", "publisher.name"}, null, true);
Iterator result = broker.getReportQueryIteratorByQuery(q);
while(result.hasNext())
{
System.out.println(ArrayUtils.toString(result.next()));
}
Result:
{21,author_1_testA_1178367631953_,publisher_testA_1178367631953_}
{22,author_2_testA_1178367631953_,publisher_testA_1178367631953_}
{23,author_3_testA_1178367631953_,publisher_testA_1178367631953_}
{24,author_4_testA_1178367631953_,publisher_testA_1178367631953_}
As you can see this works with latest version from SVN (OJB_1_0_RELEASE
branch!). I don't try this test with OJB 1.0.4. So if it's a bug in
1.0.4, it seems to be fixed in the next upcoming version of OJB.
If your problem still happens with latest from SVN, please post the
mapping for class Container and the referenced class.
regards,
Armin
Thanks in advance,
Ali
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with non decomposed M:N
Ramzi Oueslati wrote: Hi Armin, Thank you for your reply. Sure I can and here it is. This is when I try to update an already persisted instance of A : java.lang.NullPointerException at org.apache.ojb.broker.metadata.DescriptorRepository.getDescriptorFor(DescriptorRepository.java:409) at org.apache.ojb.broker.core.MtoNBroker.getMtoNImplementor(MtoNBroker.java:129) Think I got your problem. The NPE is caused by a invalid mapping. Your look like: collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList" element-class="my.test.business.C" auto-retrieve="false" auto-update="link" indirection-table="TBLAC"> a correct mapping look like: element-class-ref="org.apache.ojb.broker.sqlcount.BaseCountTest$Author" indirection-table="SQLCOUNT_PUBLICATION" proxy="true" auto-retrieve="true" auto-update="object" auto-delete="object" > as you can see it differs in one attribute, you use "element-class" instead of "element-class-ref" and this cause the NPE. By the way, it's recommended to use the latest version of OJB (1.0.4). Good luck! regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: best solution for updating many objects ?
Hi Björn,
Björn Agel wrote:
can you give a code example pls ?
im sticking in how to execute plain sql with ojb ...
you can lookup Statements from the connection and perform the update by
your own
http://db.apache.org/ojb/docu/guides/connection.html#Can+I+directly+obtain+a
or you can use OJB service classes:
broker.beginTransaction();
ClassDescriptor cld = broker.getClassDescriptor(Article.class);***
int result = broker.serviceJdbcAccess().executeUpdateSQL("UPDATE ARTICLE
A0 SET A0.TAX='23' WHERE A0.ID IN ('7','23', '34')", cld);
broker.commitTransaction();
*** If you execute plain SQL it should work with every class-descriptor,
no need to specify the correct one (but I never tried this).
regards,
Armin
thank,
Björn
Vasily Ivanov wrote:
Hi Björn,
I usually do retrieve list of IDs via OJB's
getReportQueryIteratorByQuery and then run simple plain SQL to bulk
update one field in each record by id.
Cheers,
Vasily
On 4/17/07, Björn Agel <[EMAIL PROTECTED]> wrote:
hi,
say we have a table, where many thousands objects with about 30 fields
are stored.
Now I want to update only 1 of these 30 colums for a few hundred
objects.
Atm I retrieve every single object, change 1 value and store it ...
What is the best solution for this task ?
Is there anything similar to the "ALTER TABLE" statement ?
with best regards,
Björn Agel
-
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: help with non decomposed M:N
Hi Ramzi, Ramzi Oueslati wrote: Hello everyone, I've been trying to use OJB lately but I'm a newbie and I'm stuck with handling simple non decomposed M:N relationships. Here's my purpose : ... *** You might have noticed the collections auto-retrieve setting is set to 'false'. If I set this setting to true in *A* class mapping, I get a NullPointerException when I try to read instances of A. Could you please post this stack trace too? Used version of OJB? The class mapping seems to be ok. regards, Armin Furthermore, auto-retrieve set to false, I can read and add new objects but I also get NullPointerExceptions when trying to update an object already stored. Is there anything I'm doing wrong ? Please, do not hesitate to ask me questions. Any help would be greatly appreciated. Many thanks. Ramzi Oueslati - 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]
