Re:unable to connect to hsqldb
hi, i can't connect to hsqldb. I'm using hsqldb 1.7.1 and ojb 1.0. My db is Almayer, this is my : and this is the error (from tomcat's log): at org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown Source) ... 50 more Caused by: org.apache.ojb.broker.accesslayer.LookupException: Error getting Connection from DriverManager with url (jdbc:hsqldb:hsql://localhost/almayer) and driver (org.hsqldb.jdbcDriver) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFactory.makeObject(Unknown Source) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816) ... 53 more Caused by: java.sql.SQLException: Connection is broken: localhost/almayer at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.Trace.error(Unknown Source) at org.hsqldb.jdbcConnection.reconnectHSQL(Unknown Source) at org.hsqldb.jdbcConnection.openHSQL(Unknown Source) at org.hsqldb.jdbcConnection.(Unknown Source) at org.hsqldb.jdbcDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:512) at java.sql.DriverManager.getConnection(DriverManager.java:171) ... 56 more That's all. Can somebody help me? Thanks in advance Gianluca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:unable to connect to hsqldb
hi, i can't connect to hsqldb, please save my family! I'm using hsqldb 1.7.1 and ojb 1.0. My db is Almayer, this is my : and this is the error (from tomcat's log): at org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl.getConnectionFromPool(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown Source) ... 50 more Caused by: org.apache.ojb.broker.accesslayer.LookupException: Error getting Connection from DriverManager with url (jdbc:hsqldb:hsql://localhost/almayer) and driver (org.hsqldb.jdbcDriver) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDriverManager(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl$ConPoolFactory.makeObject(Unknown Source) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:816) ... 53 more Caused by: java.sql.SQLException: Connection is broken: localhost/almayer at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.Trace.error(Unknown Source) at org.hsqldb.jdbcConnection.reconnectHSQL(Unknown Source) at org.hsqldb.jdbcConnection.openHSQL(Unknown Source) at org.hsqldb.jdbcConnection.(Unknown Source) at org.hsqldb.jdbcDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:512) at java.sql.DriverManager.getConnection(DriverManager.java:171) ... 56 more That's all. Can somebody help me? Thanks in advance Gianluca - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Loss of precsion with PersistenceBroker.store() and BigDecima l on Sybase.
Hi Armin,
I suspect the change needs to cover both ASA and ASE. I'm actually surprised
it doesn't occur on all database types given the documentation on
java.sql.PreparedStatement (see below). The setObject call made by the
default implementation is documented as setting scale specifically to zero
for both NUMERIC and DECIMAL sql types. Based on this, our testing of sybase
drivers using JDBC suggests they are correct according to the interface
documentation.
This being the case we may need the following change, or something like it,
to PlatformDefaultImpl:
/*
* @see Platform#setObject(PreparedStatement, int, Object, int)
*/
public void setObjectForStatement(PreparedStatement ps, int index,
Object value, int sqlType)
throws SQLException
{
if ((value instanceof String) && (sqlType == Types.LONGVARCHAR))
{
String s = (String) value;
ps.setCharacterStream(index, new StringReader(s), s.length());
}
// PATCH for BigDecimal truncation problem.
else if ( (value instanceof BigDecimal) && (sqlType == Types.DECIMAL
|| sqlType == Types.NUMERIC)) {
ps.setObject(index, value, sqlType,
((BigDecimal)value).scale());
}
// END BigDecimal patch.
else
{
ps.setObject(index, value, sqlType);
}
}
Java API Docs:
--
java.sql.PreparedStatement.setObject
public void setObject(int parameterIndex,
Object x,
int targetSqlType)
throws SQLException
Sets the value of the designated parameter with the given object. This
method is like the method setObject above, EXCEPT THAT IT ASSUMES A SCALE OF
ZERO.
Parameters:
parameterIndex - the first parameter is 1, the second is 2, ...
x - the object containing the input parameter value
targetSqlType - the SQL type (as defined in java.sql.Types) to be
sent to the database
Throws:
SQLException - if a database access error occurs
--
Regards
Stuart
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Monday, 29 March 2004 10:55 PM
To: OJB Users List
Subject: Re: Loss of precsion with PersistenceBroker.store() and
BigDecima l on Sybase.
Hi Stuart/Danilo
I don't use Sybase ASA or Sybase ASE, so it's hard to decide which way
to go. Can someone say what we should change in
PlatformSybaseImpl (Sybase base class)
PlatformSybaseASAImpl
PlatformSybaseASEImpl
classes to make OJB proper work with Sybase?
Does Sybase support NUMERIC (is mapped to BigDecimal too) type?
public void setObjectForStatement(PreparedStatement ps, int index,
Object value, int sqlType) throws SQLException
{
// Stuart's patch
if (sqlType == Types.DECIMAL)
{
ps.setObject(index, value);
}
else
{
super.setObjectForStatement(ps, index, value, sqlType);
}
}
regards,
Armin
Stuart Heriot wrote:
> Hi Danilo,
>
> Can't say I have much confidence in Sybase providing a permanent solution
> given your experience. We'll stick with the OJB fix for now. The
> ps.setBigDecimal() works also.
>
> Cheers
> Stuart
>
> -Original Message-
> From: Danilo Tommasina [mailto:[EMAIL PROTECTED]
> Sent: Friday, 26 March 2004 11:41 PM
> To: OJB Users List
> Subject: Re: Loss of precsion with PersistenceBroker.store() and
> BigDecima l on Sybase.
>
>
> Hi,
>
> We have the same problem with Sybase, the bug seems not to be really an
> OJB problem it is a bug in the JDBC dirver, however doing a special
> handling for BigDecimal in OJB may be a good workaround.
>
> The bug appears in several releases of the Sybase drivers and appears
> and disappears in different builds of the same driver version.
> Driver file jconn2_v55_B25089.jar (also version 5.5 Build 25089) works
> correctly for us. In the following release build, the bug is still
> present. For some reason the bug seems to be fixed and reappear in new
> driver releases on a regular basis, this is very annoying since we do
> not always have the control over wich driver releases our customer are
> using :(
> Probably using a ps.setBigDecimal(...) call (instead of
> ps.setObject(...) ) if sqlType is equal to BIG_DECIMAL would solve the
> problem.
>
> cheers
> danilo
>
>
>>Hi Stuart,
>>
>>do we need this patch for both Sybase versions (Sybase ASA, Sybase ASE)?
>>
>>regards,
>>Armin
>>
>>Stuart Heriot wrote:
>>
>>
>>>I have implemented a fix for this issue locally by modifying the Sybase
>>>Plaform dependant class (see below). I picked this up from a posting
>>>about a
>>>similar issue with DB2. The DB2 fix, however, is not in the rc5
>>>release. We
>>>need a fix to be included in the official OJB release so that we don't
>>>reintroduce this problem when implementing future releases of OJB. Is
>>>this
>>>possible? Please advise..
>>>
>>>Regards Stuart Heriot
>>>
>>>
>>>package org.apache.ojb.brok
Re: xdoclet not setting autoincrement
Thomas Dudziak wrote: On Fri, 26 Mar 2004, Laurie Harper wrote: Hi, just thought I should report this (I'd log it as a bug, but Scarab doesn't work for me :-( ): When settings the 'autoincrement' attribute of @ojb.field to 'native', the xdoclet module doesn't generate 'autoincrement' attributes in the OJB repository descriptor. These are necessary to tell OJB that these are managed fields; without them, nothing works unless you manually assign values to the autoincremented fields, defeating the point really! You may be right here (I'm not an expert when it comes to the SequenceManagerNativeImpl). I'll have a look. The problem is OJB needs to know which properties to consult the sequence manager for. Otherwise, the sequence manager doesn't get used. Setting 'autoincrement' to 'database' generates the 'autoincrement' attributes in the OJB repository descriptor fine. As far as I can tell, this is always the correct thing to do for an autoincrementing property; you then tell OJB how to manage autoincrement properties through the database connection descriptor. (Haven't figured out if there's a way to have some properties use native sequencing and some use OJB managed sequencing yet). I don't think this is possible as the connection descriptor can have at most one sequence manager which is then used for generating the sequences. Yeah, that's what it looked like to me -- though I guess you could write a seq manager that delegates to different seq managers according to the class/property it's being queried for. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: "java.lang.Long not found in OJB Repository"
That was it Thanks -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 4:05 PM To: OJB Users List Subject: Re: "java.lang.Long not found in OJB Repository" Hi, think somewhere in code you try to store a java.lang.Long object. If this wasn't the case, please post the whole stack trace. regards, Armin Mindy Pereira wrote: > Can anyone offer advice on what is causing the following error? > > ERROR 2004-03-29 15:56:21,753 > :org.apache.ojb.broker.metadata.ClassNotPersistenc > eCapableException: java.lang.Long not found in OJB Repository > > I use java.lang.Long's in other persisted beans which seem to be > working properly and am mapping them to a JDBC BIGINT. > > Thanks. > > - > 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: "java.lang.Long not found in OJB Repository"
Hi, think somewhere in code you try to store a java.lang.Long object. If this wasn't the case, please post the whole stack trace. regards, Armin Mindy Pereira wrote: Can anyone offer advice on what is causing the following error? ERROR 2004-03-29 15:56:21,753 :org.apache.ojb.broker.metadata.ClassNotPersistenc eCapableException: java.lang.Long not found in OJB Repository I use java.lang.Long's in other persisted beans which seem to be working properly and am mapping them to a JDBC BIGINT. Thanks. - 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]
"java.lang.Long not found in OJB Repository"
Can anyone offer advice on what is causing the following error? ERROR 2004-03-29 15:56:21,753 :org.apache.ojb.broker.metadata.ClassNotPersistenc eCapableException: java.lang.Long not found in OJB Repository I use java.lang.Long's in other persisted beans which seem to be working properly and am mapping them to a JDBC BIGINT. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Still Probleml with Mapping Inheritance Hierarchies
I can reproduce this problem with OJB 1.0rc6.
Appear that when two or more tables with same PKs, with identical values
for their PKs have the following behaviour:
a) Get Identity for the first object. Get the object by Identity. Put it
in the ChainingIterator
b) Get Identity for second object. Since this identity is already
(remeber, the values of the PKs are the same), don't get the object
again. Just put it again.
c) and so on.
I don't know if this is the real steps done inside OJB (I tryied to
debug, but I must admit it's so much complex to me), but as far as I can
get debugged, is this that is occuring.
I think that the test should be made against the same PK and
getClass().getName(). If two are same, then the object is already inside
(and, if user asked for distinct, should not add repeated anyway).
Otherwise, should exect a getByIdentity using the correct table.
What do you think all?
Can someone test the extent tests using values in different tables with
same PK?
As workaround, I added ojbConcreteClass to my class-descriptor as PK,
and works fine (but I think it's a very, really bad solution).
Behaviour is same with or without proxies.
Best regards,
Edson Richter
Edson Carlos Ericksson Richter wrote:
Hi!
I don't know if this solves your problem, but AFAIK, you can't mix
with , as you have done in
class-descriptor for A class.
More, I have no luck in using extent-class using a Interface as
super-object. Have you tried an ABAbstractClass (I'm just trying a
sidekick)?
Best regards,
Edson Richter
Björn Voigt wrote:
OK, I have still no solution for my inheritance mapping problem.
There are my Classes A,B and C implementing the ABInterface, C and B
extend from A. I want to map each class to a distinct tables, but
on Multiple Joined Tables. The c an b table have its own primary
column "b_id" and "c_id" and both a foreign key "a_id" referenes the
a table.
Table A: Table B:
id | some_value_from_a b_id | a_id | some_value_from_b
+--- --+--+---
1 | 1000100 |1 | 1001
2 | 2000
Table C:
c_id | a_id | some_value_from_c
--+--+---
101 |2 | 2002
Ok, if I query the ABInterface I want have two
instances, one of B and one of C, something like this:
instance test.B id:1 a_value:1000 b_value:1001
instance test.C id:2 a_value:2000 c_value:2002
But I get also instances of A, a query has this result:
instance test.A id:1 a_value:1000
instance test.A id:2 a_value:2000
instance test.B id:1 a_value:1000 b_value:1001
instance test.C id:2 a_value:2000 c_value:2002
But thats not all:
instance into b values (1, 1, 1001); instead of:
instance into b values (100, 1, 1001);
has the following query-result:
instance test.A id:1 a_value:1000
instance test.A id:2 a_value:2000
instance test.A id:1 a_value:1000
instance test.C id:2 a_value:2000 c_value:2002
if b_id equals to an id of the a-table, or b_id equals
to a c_id in c-table, the result is another.
I am using rc5 and would be very happy, if you
can help me or give me an working example.
Björn Voigt
Here follows my complete source code:
package test;
public class A implements ABInterface{
int id;
int someValueFromA;
public String toString() {
return this.getClass() + " id:" +id +" a_value:" +
someValueFromA;
}
}
package test;
public class B extends A {
int b_id;
int someValueFromB;
public String toString() {
return super.toString() + " b_value:" + someValueFromB;
}
}
package test;
public class C extends A {
int c_id;
int someValueFromC;
public String toString() {
return super.toString() + " c_value:" + someValueFromC;
}
}
primarykey="true" autoincrement="true" />
primarykey="true" autoincrement="true" />
-
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: Insert instead of update generated in RC6
Hi again,
all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and
MaxDB. Maybe I forget to write a test for object update ;-).
> Does ist help? I can not see your Methods at the stack trace. Is it
> possible, that the cache is never checked?
You can't see one of these methods in your stack trace, bacause these
methods maybe generate a wrong value for boolean 'doInsert' in your case.
The change made between rc5 to rc6 is a new check
serviceBrokerHelper().hasNullPKField(cld, obj);
and the
deletedDuringTransaction.contains(oid);
check. Is it possible that you pass a nullified PK field (declared in
decriptor) when you update an object? In that case OJB try to insert the
object.
I think you have two possibilities:
- remote debugging of this part of PBImpl class to see if a wrong
boolean value was set - signals insert instead of update.
- Put some System.out.println to check the boolean or/and comment out
the new stuff and see what's going on.
regards,
Armin
Guido Beutler wrote:
Armin Waibel wrote:
Hi Guido,
Guido Beutler wrote:
Hello,
I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with
DB2 V8.
Since update to RC6 OJB generates a insert for every stored object
when using PB API.
OJB seems not to check if the object exists at database. If the
object already exist,
a SQL Exception is thrown. (-803 which means dublicated PK). If I try
to insert the same object
several times, every time the same exception is thrown. If I select
the object first, OJB generates a insert too.
I tried the same with RC5 (just to be sure that it is not a error at
the test case) and RC5 works as expected.
If the object exist a update is generated.
Did I miss something or is it a new issue?
hmm, in PBImpl we do:
ClassDescriptor cld = getClassDescriptor(obj.getClass());
/*
if one of the PK fields was null, the objects was new
and needs insert
*/
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
//if one of the PK field represents 'null' OJB assume the object is new
Identity oid = new Identity(obj, this, cld);
/*
if the object has been deleted during this transaction,
then we must insert it
*/
boolean shouldRemoveFromDeleted = false;
if (!doInsert)
{
doInsert = deletedDuringTransaction.contains(oid);
shouldRemoveFromDeleted = true;
}
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
// now store it:
store(obj, oid, cld, doInsert);
Which of these methods returns a wrong result?
regards,
Armin
Hi Armin, :-)
that's the stacktrace:
org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while
insert object data for class
...
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:242)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1620)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1537)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:683)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
And here's the Cache related stuff from ojb.properties:
#
# Object cache
#
# The ObjectCacheClass entry tells OJB which concrete ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info see documentation.
#
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per class-descriptor object-cache
# declaration was used in conjunction with metadata runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is used as key to
# find a per class ObjectCache, this enables to use different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before caching methods were
# called. Build your own filter class by implementing
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of CacheFi
Re: 1:0..1 mappings and dynamic proxies (was Re: [ann] new release 1.0.RC6)
hi edson,
maybe we have just discovered another configurable feature of ojb.
check-existence-of-proxy = 'true' on the relationship-definition.
jakob
Edson Carlos Ericksson Richter wrote:
An un-elegant way to do same withou select count:
try {
String x = myXobject.getY().toString();
} catch(NullPointerException e) {
... do something because there is no Y...
}
The question is: what cost more? Doing a select count(*) over a indexed
(primary key) field, with all network overhead, or catching a NPE?
Best regards,
Edson Richter
Jakob Braeuchi wrote:
hi edson,
executing an additional count on each reference proxy is quite
expensive. but i have to admit, i do not have a better solution right
now :(
jakob
Edson Carlos Ericksson Richter wrote:
Still with problems when using a 1:0..1 mapping + proxy="dynamic".
The problem is:
when making a reference between two objects (X:Y) and there can be 0
or 1 object in Y side, Y must resturn NULL if it don't exists in
database, and the object itself if there is 1 object in database. The
rule is maintained using same PK for two tables, a foreign key to
guarantee data integrity, and a NULL allowed in the X side to allow 0
values in Y side.
the error is seen when using "proxy='dynamic'" because OJB set,
internally, the value to a dynamic proxy. In the code, when you test
"myXobject.getY()==null" the result is always false, because getY is
returnin a non-materialized proxy. The following code will always
throw NPE when are 0 Y objects for a X object (but if proxy="false",
there is no error):
if(myXobject.getY()!=null) {
// It always get into here, even when there is no Y value!!!
System.out.println(myXobject.getY().getId());
// the previous line will throw NPE, because when acessisng getId(),
OJB will try to materialize,
// since there is no Y object, will try to execute getId() over a
null materialized.
}
This sayid, I think OJB should execute a count when using a reference
as proxy, and when there is 0 object, return null, not a
unmaterialized proxy (so the null test in code above will have same
behaviour as if it's not proxy).
What you say?
Best regards,
Edson Richter
Best regards,
Edson Richter
Armin Waibel wrote:
Hi Edson,
[EMAIL PROTECTED] wrote:
Hmmm, what about the "1:0..1 and proxies test for null is always
false" and the "afterStore
not being called for collections"? Are they fixed too?
Sorry I don't know. While refactoring the handling of the auto-xxx
code I do my best, but I don't turn my attention to these problems.
Could you review/test the rc6/CVS code and repost the problematic
spots?
regards,
Armin
Best regards,
Edson Richter
Dear all,
We've got a new release! Given we find no showstoppers during the
next
week we will approach the Project Management Committee (PMC) of the
db.apache.org project to get approval to relabel this release as the
final 1.0 version.
Armin worked hard to get our regression testbed rocksolid. We now
have
more than 600 testcases covering all major areas of the framework!
I'm confident that this testsuite will help us to maintain and even
increse the reliability of our code from release to release.
Thanks to all who helped and contributed to this release!
--Thomas
From the release notes:
-
Release 1.0 rc6
-
NEW FEATURES:
-
NOTES:
- Repository.dtd has changed, don't forget to replace this file
- Upgraded to the new Apache License, Version 2.0
- No support for HSQLDB 1.7.2RC1 yet
- No support for Torque 3.1 yet
- Add new PersistenceBrokerFactory implementation for use in managed
environments when *only* the
PB-api was used and participation in JTA transaction via
Synchronization
interface is needed.
- Add new configuration property 'autoSync' to
ObjectCacheDefaultImpl.
Used to enable a simple
synchronization mechanism to keep cache in sync with DB
- Add new attribute values for reference-/collection-descriptor
auto-update/-delete attribute.
Now we have five possible values: none, link, object, true, false.
The
true, false values
are now deprecated but will NOT be removed in near future (so
don't panic!).
CHANGES:
- fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was
INTEGER but
needs BIGINT to support Long on java side
- no longer throw an exception when calling abortTransaction more
than
one time
or an internal rollback (by ConnectionManager on the used connection)
was already done
- Add object-cache tag in standard jdbc-connection-descriptor in
repository_database.xml
to enable new 'autoSync' property of ObjectCacheDefaultImpl for all
operations made by
this DB connection
- Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl
(handle with care ;-))
- odmg-api implementation, disable restore of transient objects on
transaction abort,
because we can't really restore the whole object with all references
- now usi
Re: 1:0..1 mappings and dynamic proxies (was Re: [ann] new release 1.0.RC6)
An un-elegant way to do same withou select count:
try {
String x = myXobject.getY().toString();
} catch(NullPointerException e) {
... do something because there is no Y...
}
The question is: what cost more? Doing a select count(*) over a indexed
(primary key) field, with all network overhead, or catching a NPE?
Best regards,
Edson Richter
Jakob Braeuchi wrote:
hi edson,
executing an additional count on each reference proxy is quite
expensive. but i have to admit, i do not have a better solution right
now :(
jakob
Edson Carlos Ericksson Richter wrote:
Still with problems when using a 1:0..1 mapping + proxy="dynamic".
The problem is:
when making a reference between two objects (X:Y) and there can be 0
or 1 object in Y side, Y must resturn NULL if it don't exists in
database, and the object itself if there is 1 object in database. The
rule is maintained using same PK for two tables, a foreign key to
guarantee data integrity, and a NULL allowed in the X side to allow 0
values in Y side.
the error is seen when using "proxy='dynamic'" because OJB set,
internally, the value to a dynamic proxy. In the code, when you test
"myXobject.getY()==null" the result is always false, because getY is
returnin a non-materialized proxy. The following code will always
throw NPE when are 0 Y objects for a X object (but if proxy="false",
there is no error):
if(myXobject.getY()!=null) {
// It always get into here, even when there is no Y value!!!
System.out.println(myXobject.getY().getId());
// the previous line will throw NPE, because when acessisng getId(),
OJB will try to materialize,
// since there is no Y object, will try to execute getId() over a
null materialized.
}
This sayid, I think OJB should execute a count when using a reference
as proxy, and when there is 0 object, return null, not a
unmaterialized proxy (so the null test in code above will have same
behaviour as if it's not proxy).
What you say?
Best regards,
Edson Richter
Best regards,
Edson Richter
Armin Waibel wrote:
Hi Edson,
[EMAIL PROTECTED] wrote:
Hmmm, what about the "1:0..1 and proxies test for null is always
false" and the "afterStore
not being called for collections"? Are they fixed too?
Sorry I don't know. While refactoring the handling of the auto-xxx
code I do my best, but I don't turn my attention to these problems.
Could you review/test the rc6/CVS code and repost the problematic
spots?
regards,
Armin
Best regards,
Edson Richter
Dear all,
We've got a new release! Given we find no showstoppers during the
next
week we will approach the Project Management Committee (PMC) of the
db.apache.org project to get approval to relabel this release as the
final 1.0 version.
Armin worked hard to get our regression testbed rocksolid. We now
have
more than 600 testcases covering all major areas of the framework!
I'm confident that this testsuite will help us to maintain and even
increse the reliability of our code from release to release.
Thanks to all who helped and contributed to this release!
--Thomas
From the release notes:
-
Release 1.0 rc6
-
NEW FEATURES:
-
NOTES:
- Repository.dtd has changed, don't forget to replace this file
- Upgraded to the new Apache License, Version 2.0
- No support for HSQLDB 1.7.2RC1 yet
- No support for Torque 3.1 yet
- Add new PersistenceBrokerFactory implementation for use in managed
environments when *only* the
PB-api was used and participation in JTA transaction via
Synchronization
interface is needed.
- Add new configuration property 'autoSync' to
ObjectCacheDefaultImpl.
Used to enable a simple
synchronization mechanism to keep cache in sync with DB
- Add new attribute values for reference-/collection-descriptor
auto-update/-delete attribute.
Now we have five possible values: none, link, object, true, false.
The
true, false values
are now deprecated but will NOT be removed in near future (so
don't panic!).
CHANGES:
- fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was
INTEGER but
needs BIGINT to support Long on java side
- no longer throw an exception when calling abortTransaction more
than
one time
or an internal rollback (by ConnectionManager on the used connection)
was already done
- Add object-cache tag in standard jdbc-connection-descriptor in
repository_database.xml
to enable new 'autoSync' property of ObjectCacheDefaultImpl for all
operations made by
this DB connection
- Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl
(handle with care ;-))
- odmg-api implementation, disable restore of transient objects on
transaction abort,
because we can't really restore the whole object with all references
- now using ANTLR 2.7.2 and Unicode support in OQL queries
- now using ANT 1.6.0
- RelationshipPrefetcher no longer modifies auto-retrieve setting of
Relationship-Descriptor.
This may result in addit
Re: Insert instead of update generated in RC6
Armin Waibel wrote:
Hi Guido,
Guido Beutler wrote:
Hello,
I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with
DB2 V8.
Since update to RC6 OJB generates a insert for every stored object
when using PB API.
OJB seems not to check if the object exists at database. If the
object already exist,
a SQL Exception is thrown. (-803 which means dublicated PK). If I try
to insert the same object
several times, every time the same exception is thrown. If I select
the object first, OJB generates a insert too.
I tried the same with RC5 (just to be sure that it is not a error at
the test case) and RC5 works as expected.
If the object exist a update is generated.
Did I miss something or is it a new issue?
hmm, in PBImpl we do:
ClassDescriptor cld = getClassDescriptor(obj.getClass());
/*
if one of the PK fields was null, the objects was new
and needs insert
*/
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
//if one of the PK field represents 'null' OJB assume the object is new
Identity oid = new Identity(obj, this, cld);
/*
if the object has been deleted during this transaction,
then we must insert it
*/
boolean shouldRemoveFromDeleted = false;
if (!doInsert)
{
doInsert = deletedDuringTransaction.contains(oid);
shouldRemoveFromDeleted = true;
}
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
// now store it:
store(obj, oid, cld, doInsert);
Which of these methods returns a wrong result?
regards,
Armin
Hi Armin, :-)
that's the stacktrace:
org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while
insert object data for class
...
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:242)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1620)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1537)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:683)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
And here's the Cache related stuff from ojb.properties:
#
# Object cache
#
# The ObjectCacheClass entry tells OJB which concrete ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info see documentation.
#
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per class-descriptor object-cache
# declaration was used in conjunction with metadata runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is used as key to
# find a per class ObjectCache, this enables to use different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before caching methods were
# called. Build your own filter class by implementing
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of CacheFilters, but this slows
# down the performance of the cache, thus handle with care.
#
# - org.apache.ojb.broker.cache.CacheFilterClassImpl
# allows filtering of classes
# - org.apache.ojb.broker.cache.CacheFilterPackageImpl
# allows filtering of packages
# More info see Javadoc of the according classes.
# Set a comma separated list of CacheFilter.
#ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
#
Does ist help? I can not see your Methods at the stack trace. Is it
possible, that the cache is never checked?
best regards,
Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie at a standstill
Are you using the ant build? The ojb-blank project template does a
property replace in the build -- the required database information is
in the build.properties and is copied into the generated
repository_database.xml that goes in build/ when compilation is run.
-Brian
On Mar 29, 2004, at 11:24 AM, [EMAIL PROTECTED] wrote:
I am trying to get OJB working and am getting absolutely nowhere, so I
appeal to the list for some help.
The environment is OJB rc5, Eclipse IDE, Sun JDK1.4.2, Oracle 9,
NT4.0. The
running of the code is controlled by JUnit.
I can connect to the DB both with sqlplus and jdbc. I cannot actually
get
OJB to connect. Clearly I am missing something, but I cannot discover
what.
By fiddling around with the XML I can generate various sorts of
errors. In
all cases the url that the system is using appears to be entirely
palusible.
Here are the code, the repository_database.xml and the output:
Code:
/*
* Created on 26-Mar-2004
* CVS version $Header:$
*/
package com.gsk.bet;
import java.util.*;
import java.sql.*;
import junit.framework.*;
import org.apache.ojb.broker.*;
import org.apache.ojb.broker.query.*;
import org.odmg.*;
import org.apache.ojb.odmg.*;
import com.gsk.bet.Entity;
/**
* @author rxm1676
* @company GSK
*/
public class ConnectionTest extends TestCase {
PersistenceBroker broker;
Database db = null;
Implementation odmg = null;
public void setUp() {
try {
Class c =
Class.forName("oracle.jdbc.driver.OracleDriver"
);
broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
odmg = OJB.getInstance();
db = odmg.newDatabase();
db.open("BETConnection", Database.OPEN_READ_WRITE);
} catch (Exception ex) {
System.out.println(ex);
}
}
public void tearDown() {
if (broker != null) {
broker.close();
}
if (db != null) {
try {
db.close();
} catch (ODMGException ex2) {
}
}
}
/**
* Null test. Just checks that OJB is properly installed, that
it can
see both the
* XML and the bean classes, and that we can get a Broker and an
ODMG
instance.
*
*/
public void testConnection() {
}
/**
* Ensure that we can actually talk to the DB from this machine
*
*/
public void testRawJDBC()
{
try {
Connection con = DriverManager.getConnection
("jdbc:oracle:thin:@ukt01368.ggr.co.uk:1521:TOOLS", "bet",
"");
PreparedStatement sth = con.prepareStatement("select * from
entity
where betid<10");
ResultSet res = sth.executeQuery();
System.out.println("Excuted raw query");
while (res.next()) {
Entity ent = new Entity();
ent.setBetid(res.getInt("BETID"));
ent.setEntityType(res.getString("ENTITYTYPE"));
ent.setDescriptor(res.getString("DESCRIPTOR"));
System.out.println("raw retrieval of "+ent);
}
res.close();
con.close();
} catch (Exception e) {
System.out.println("Caught raw exception " + e);
}
}
/**
*
* @author rxm1676
* @company GSK
*/
public void testODMGFetchSingle() {
Transaction tx = odmg.newTransaction();
try {
OQLQuery query = odmg.newOQLQuery();
query.create(
"select betid, entityType, descriptor from " +
Entity.class.getName() + " where betid = 1");
DList results = (DList)query.execute();
for (Iterator iter = results.iterator();
iter.hasNext();)
{
tx.begin();
Entity res = (Entity)iter.next();
System.out.println("Retrieved " + res);
tx.commit();
}
} catch (QueryInvalidException qie) {
System.out.println(qie);
tx.abort();
} catch (QueryException qe) {
System.out.println(qe);
tx.abort();
}
}
/**
* Retrieve a single object using the PersistenceBroker
* @author rxm1676
* @company GSK
*/
public void testPBFetchSingle()
{
Entity example = new Entity();
example.setBetid(1);
Query q = QueryFactory.newQueryByExample(example);
Entity res = (Entity)broker.getObjectByQuery(q);
System.out.println("PB fetched "+res);
}
}
Database_repopsitory.xml
="org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl">
="false"/>
="1"/>
Re: 1:0..1 mappings and dynamic proxies (was Re: [ann] new release 1.0.RC6)
hi edson,
executing an additional count on each reference proxy is quite expensive. but i
have to admit, i do not have a better solution right now :(
jakob
Edson Carlos Ericksson Richter wrote:
Still with problems when using a 1:0..1 mapping + proxy="dynamic".
The problem is:
when making a reference between two objects (X:Y) and there can be 0 or
1 object in Y side, Y must resturn NULL if it don't exists in database,
and the object itself if there is 1 object in database. The rule is
maintained using same PK for two tables, a foreign key to guarantee data
integrity, and a NULL allowed in the X side to allow 0 values in Y side.
the error is seen when using "proxy='dynamic'" because OJB set,
internally, the value to a dynamic proxy. In the code, when you test
"myXobject.getY()==null" the result is always false, because getY is
returnin a non-materialized proxy. The following code will always throw
NPE when are 0 Y objects for a X object (but if proxy="false", there is
no error):
if(myXobject.getY()!=null) {
// It always get into here, even when there is no Y value!!!
System.out.println(myXobject.getY().getId());
// the previous line will throw NPE, because when acessisng getId(),
OJB will try to materialize,
// since there is no Y object, will try to execute getId() over a null
materialized.
}
This sayid, I think OJB should execute a count when using a reference as
proxy, and when there is 0 object, return null, not a unmaterialized
proxy (so the null test in code above will have same behaviour as if
it's not proxy).
What you say?
Best regards,
Edson Richter
Best regards,
Edson Richter
Armin Waibel wrote:
Hi Edson,
[EMAIL PROTECTED] wrote:
Hmmm, what about the "1:0..1 and proxies test for null is always
false" and the "afterStore
not being called for collections"? Are they fixed too?
Sorry I don't know. While refactoring the handling of the auto-xxx
code I do my best, but I don't turn my attention to these problems.
Could you review/test the rc6/CVS code and repost the problematic spots?
regards,
Armin
Best regards,
Edson Richter
Dear all,
We've got a new release! Given we find no showstoppers during the next
week we will approach the Project Management Committee (PMC) of the
db.apache.org project to get approval to relabel this release as the
final 1.0 version.
Armin worked hard to get our regression testbed rocksolid. We now have
more than 600 testcases covering all major areas of the framework!
I'm confident that this testsuite will help us to maintain and even
increse the reliability of our code from release to release.
Thanks to all who helped and contributed to this release!
--Thomas
From the release notes:
-
Release 1.0 rc6
-
NEW FEATURES:
-
NOTES:
- Repository.dtd has changed, don't forget to replace this file
- Upgraded to the new Apache License, Version 2.0
- No support for HSQLDB 1.7.2RC1 yet
- No support for Torque 3.1 yet
- Add new PersistenceBrokerFactory implementation for use in managed
environments when *only* the
PB-api was used and participation in JTA transaction via
Synchronization
interface is needed.
- Add new configuration property 'autoSync' to ObjectCacheDefaultImpl.
Used to enable a simple
synchronization mechanism to keep cache in sync with DB
- Add new attribute values for reference-/collection-descriptor
auto-update/-delete attribute.
Now we have five possible values: none, link, object, true, false. The
true, false values
are now deprecated but will NOT be removed in near future (so don't
panic!).
CHANGES:
- fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was
INTEGER but
needs BIGINT to support Long on java side
- no longer throw an exception when calling abortTransaction more than
one time
or an internal rollback (by ConnectionManager on the used connection)
was already done
- Add object-cache tag in standard jdbc-connection-descriptor in
repository_database.xml
to enable new 'autoSync' property of ObjectCacheDefaultImpl for all
operations made by
this DB connection
- Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl
(handle with care ;-))
- odmg-api implementation, disable restore of transient objects on
transaction abort,
because we can't really restore the whole object with all references
- now using ANTLR 2.7.2 and Unicode support in OQL queries
- now using ANT 1.6.0
- RelationshipPrefetcher no longer modifies auto-retrieve setting of
Relationship-Descriptor.
This may result in additional sql-queries but is safer in a
multi-threaded environment.
- Added column methods to Criteria. addColumnEqualTo, addColumnIn etc.
The column parameter
of these methods will not be translated during sql-generation. These
methods are mainly used
for internal purpose.
BUG FIXES:
Please refer to our Bug tracking site
(http://issues.apache.org/scarab/servlet/scarab/)
under http:/
Re: auto-delete does not work anymore: rc6???
Hi Andreas, I made a quick test. It works for me. Did you replace the repository.dtd? Can you post the source code snip? regards, Armin Andreas Bohnert wrote: hello everbody, today I checked out the rc6 cvs version and did some validation tests on my application. I found out, that there is something going wrong, when I delete an object. I have an decomposed n-m relation: CONTACT INSTITUTION_CONTACT --- INSTITUTION when I delete an INSTITUTION_CONTACT the related INSTITUTION and the CONTACT are deleted as well!! I have put an auto-delete=false in my metadata, so I don't see a reason for that action. here is the metadata for INSTITUTION_CONTACT : class-descriptor class="at.weberhofer.eusoda.shared.orm.Institution_Contact" table="institution_contact" - 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-criteria pathClass [was ojb-user: Query casts] 2 of 2
hi phil,
thanks for the file.
generating a patch in eclipse is quite easy (in most cases). seems you
reformatted the code in some way, so the diff get's out of sync.
i'll have a look at your changes when i return from my vacation, that's 19. april.
jakob
Phil Warrick wrote:
Hi Jakob,
I applied my changes to 1.70 and am sending you the entire java file. I
created a patch file with eclipse, but it did not seem to want to do an
intelligent diff (just -entire old file contents and +entire new file
contents). There was no improvement if I turned off ignore whitespace
in the compare preferences. Maybe there's some eclipse trick I need to
know here.
Anyway, hopefully now you have all my work related to this change.
Looking forward to your feedback,
Phil
package org.apache.ojb.broker.accesslayer.sql;
/* Copyright 2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.util.ArrayList;
import java.util.Collection;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import org.apache.ojb.broker.PersistenceBrokerSQLException;
import org.apache.ojb.broker.accesslayer.JoinSyntaxTypes;
import org.apache.ojb.broker.metadata.ClassDescriptor;
import org.apache.ojb.broker.metadata.CollectionDescriptor;
import org.apache.ojb.broker.metadata.DescriptorRepository;
import org.apache.ojb.broker.metadata.FieldDescriptor;
import org.apache.ojb.broker.metadata.FieldHelper;
import org.apache.ojb.broker.metadata.ObjectReferenceDescriptor;
import
org.apache.ojb.broker.metadata.fieldaccess.AnonymousPersistentFieldForInheritance;
import org.apache.ojb.broker.platforms.Platform;
import org.apache.ojb.broker.query.*;
import org.apache.ojb.broker.util.SqlHelper;
import org.apache.ojb.broker.util.SqlHelper.PathInfo;
import org.apache.ojb.broker.util.logging.Logger;
import org.apache.ojb.broker.util.logging.LoggerFactory;
/**
* Model a Statement based on Query.
*
* @author mailto:[EMAIL PROTECTED]">Jakob Braeuchi
* @version $Id: SqlQueryStatement.java,v 1.68 2004/03/11 18:16:08 brianm Exp $
*/
public abstract class SqlQueryStatement implements SqlStatement, JoinSyntaxTypes
{
private SqlQueryStatement m_parentStatement;
/** the logger */
private Logger m_logger;
/** the target table of the query */
private TableAlias m_root;
/** the search table of the query */
private TableAlias m_search;
/** the query */
private QueryByCriteria m_query;
/** the mapping of paths to TableAliases */
private HashMap m_pathToAlias = new HashMap();
/** maps trees of joins to criteria */
private HashMap m_joinTreeToCriteria = new HashMap();
private Platform m_platform;
private ClassDescriptor m_baseCld;
private ClassDescriptor m_searchCld;
private int m_aliasCount = 0;
/**
* Constructor for SqlCriteriaStatement.
*
* @param pf the Platform
* @param cld the ClassDescriptor
* @param query the Query
* @param logger the Logger
*/
public SqlQueryStatement(Platform pf, ClassDescriptor cld, Query query, Logger
logger)
{
this(null, pf, cld, query, logger);
}
/**
* Constructor for SqlCriteriaStatement.
*
* @param parent the Parent Query
* @param pf the Platform
* @param cld the ClassDescriptor
* @param query the Query
* @param logger the Logger
*/
public SqlQueryStatement(SqlQueryStatement parent, Platform pf,
ClassDescriptor cld, Query query, Logger logger)
{
m_logger = logger != null ? logger :
LoggerFactory.getLogger(SqlQueryStatement.class);
m_parentStatement = parent;
m_query = (QueryByCriteria) query;
m_platform = pf;
m_searchCld = cld;
if ((m_query == null) || (m_query.getBaseClass() ==
m_query.getSearchClass()))
{
m_baseCld = m_searchCld;
}
else
{
m_baseCld =
cld.getRepository().getDescriptorFor(query.getBaseClass());
}
m_root = createTableAlias(m_baseCld, null, "");
if (m_searchCld
Re: Insert instead of update generated in RC6
Hi Guido,
Guido Beutler wrote:
Hello,
I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with DB2
V8.
Since update to RC6 OJB generates a insert for every stored object when
using PB API.
OJB seems not to check if the object exists at database. If the object
already exist,
a SQL Exception is thrown. (-803 which means dublicated PK). If I try to
insert the same object
several times, every time the same exception is thrown. If I select the
object first, OJB generates a insert too.
I tried the same with RC5 (just to be sure that it is not a error at the
test case) and RC5 works as expected.
If the object exist a update is generated.
Did I miss something or is it a new issue?
hmm, in PBImpl we do:
ClassDescriptor cld = getClassDescriptor(obj.getClass());
/*
if one of the PK fields was null, the objects was new
and needs insert
*/
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
//if one of the PK field represents 'null' OJB assume the object is new
Identity oid = new Identity(obj, this, cld);
/*
if the object has been deleted during this transaction,
then we must insert it
*/
boolean shouldRemoveFromDeleted = false;
if (!doInsert)
{
doInsert = deletedDuringTransaction.contains(oid);
shouldRemoveFromDeleted = true;
}
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
// now store it:
store(obj, oid, cld, doInsert);
Which of these methods returns a wrong result?
regards,
Armin
best regards,
Guido
-
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]
Newbie at a standstill
I am trying to get OJB working and am getting absolutely nowhere, so I
appeal to the list for some help.
The environment is OJB rc5, Eclipse IDE, Sun JDK1.4.2, Oracle 9, NT4.0. The
running of the code is controlled by JUnit.
I can connect to the DB both with sqlplus and jdbc. I cannot actually get
OJB to connect. Clearly I am missing something, but I cannot discover what.
By fiddling around with the XML I can generate various sorts of errors. In
all cases the url that the system is using appears to be entirely
palusible.
Here are the code, the repository_database.xml and the output:
Code:
/*
* Created on 26-Mar-2004
* CVS version $Header:$
*/
package com.gsk.bet;
import java.util.*;
import java.sql.*;
import junit.framework.*;
import org.apache.ojb.broker.*;
import org.apache.ojb.broker.query.*;
import org.odmg.*;
import org.apache.ojb.odmg.*;
import com.gsk.bet.Entity;
/**
* @author rxm1676
* @company GSK
*/
public class ConnectionTest extends TestCase {
PersistenceBroker broker;
Database db = null;
Implementation odmg = null;
public void setUp() {
try {
Class c = Class.forName("oracle.jdbc.driver.OracleDriver"
);
broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
odmg = OJB.getInstance();
db = odmg.newDatabase();
db.open("BETConnection", Database.OPEN_READ_WRITE);
} catch (Exception ex) {
System.out.println(ex);
}
}
public void tearDown() {
if (broker != null) {
broker.close();
}
if (db != null) {
try {
db.close();
} catch (ODMGException ex2) {
}
}
}
/**
* Null test. Just checks that OJB is properly installed, that it can
see both the
* XML and the bean classes, and that we can get a Broker and an ODMG
instance.
*
*/
public void testConnection() {
}
/**
* Ensure that we can actually talk to the DB from this machine
*
*/
public void testRawJDBC()
{
try {
Connection con = DriverManager.getConnection
("jdbc:oracle:thin:@ukt01368.ggr.co.uk:1521:TOOLS", "bet", "");
PreparedStatement sth = con.prepareStatement("select * from entity
where betid<10");
ResultSet res = sth.executeQuery();
System.out.println("Excuted raw query");
while (res.next()) {
Entity ent = new Entity();
ent.setBetid(res.getInt("BETID"));
ent.setEntityType(res.getString("ENTITYTYPE"));
ent.setDescriptor(res.getString("DESCRIPTOR"));
System.out.println("raw retrieval of "+ent);
}
res.close();
con.close();
} catch (Exception e) {
System.out.println("Caught raw exception " + e);
}
}
/**
*
* @author rxm1676
* @company GSK
*/
public void testODMGFetchSingle() {
Transaction tx = odmg.newTransaction();
try {
OQLQuery query = odmg.newOQLQuery();
query.create(
"select betid, entityType, descriptor from " +
Entity.class.getName() + " where betid = 1");
DList results = (DList)query.execute();
for (Iterator iter = results.iterator(); iter.hasNext();)
{
tx.begin();
Entity res = (Entity)iter.next();
System.out.println("Retrieved " + res);
tx.commit();
}
} catch (QueryInvalidException qie) {
System.out.println(qie);
tx.abort();
} catch (QueryException qe) {
System.out.println(qe);
tx.abort();
}
}
/**
* Retrieve a single object using the PersistenceBroker
* @author rxm1676
* @company GSK
*/
public void testPBFetchSingle()
{
Entity example = new Entity();
example.setBetid(1);
Query q = QueryFactory.newQueryByExample(example);
Entity res = (Entity)broker.getObjectByQuery(q);
System.out.println("PB fetched "+res);
}
}
Database_repopsitory.xml
Output:
Excuted raw query
raw retrieval of BET ID: 1 EntityType: Protein Descriptor;null
raw retrieval of BET ID: 2 EntityType: Protein Descriptor;null
raw retrieval of BET ID: 3 EntityType: Protein Descriptor;null
raw retrieval of BET ID: 4 EntityType: Protein Descriptor;null
raw retrieva
Insert instead of update generated in RC6
Hello, I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with DB2 V8. Since update to RC6 OJB generates a insert for every stored object when using PB API. OJB seems not to check if the object exists at database. If the object already exist, a SQL Exception is thrown. (-803 which means dublicated PK). If I try to insert the same object several times, every time the same exception is thrown. If I select the object first, OJB generates a insert too. I tried the same with RC5 (just to be sure that it is not a error at the test case) and RC5 works as expected. If the object exist a update is generated. Did I miss something or is it a new issue? best regards, Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
auto-delete does not work anymore: rc6???
hello everbody, today I checked out the rc6 cvs version and did some validation tests on my application. I found out, that there is something going wrong, when I delete an object. I have an decomposed n-m relation: CONTACT INSTITUTION_CONTACT --- INSTITUTION when I delete an INSTITUTION_CONTACT the related INSTITUTION and the CONTACT are deleted as well!! I have put an auto-delete=false in my metadata, so I don't see a reason for that action. here is the metadata for INSTITUTION_CONTACT : class-descriptor class="at.weberhofer.eusoda.shared.orm.Institution_Contact" table="institution_contact" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ann] new release 1.0.RC6
The problem that I ran into was that the version of PlatformDb2Impl from rc4 didn't have a query for getLastInsertIdentityQuery(), and the query for rc5 is "values IDENTITY_VAL_LOCAL() fetch first row only" which, when executed in my env generates the exception "The SQL statement is not supported SQLSTATE=42612" (but just because it doesn't work in my DB2 database, doesn't mean the statement doesn't work for someone else's DB2 -- Its probably a DB configuration thing) So I had to extend PlatformDb2Impl and override getLastInsertIdentityQuery() so that I could use the query "SELECT IDENTITY_VAL_LOCAL() FROM SYSIBM.SYSDUMMY1" which works for me. Other than that I am ok, and if other people complain about the "values IDENTITY_VAL_LOCAL() fetch first row only" query, then I would suggest trying the other query. I don't know enough about DB2 to suggest that one query is better than the other. All I know is that only one query worked for me. -Original Message- From: Glenn Barnard [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 7:54 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ann] new release 1.0.RC6 Congratulations!!! I have a couple of questions... First, will it have a debuggable version? rc5 didn't (at least as far as I could see)? McCaffrey, John G. <[EMAIL PROTECTED]> and I have been working with OJB to get the primary key from a native sequence manager. John's using DB2 and I'm using MS SQL Server. Seems like John's solution works, but mine isn't (yet). When can we get our solutions included with the base code? >From: Thomas Mahler <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: OJB Developers List <[EMAIL PROTECTED]>, OJB Users List ><[EMAIL PROTECTED]> >Subject: [ann] new release 1.0.RC6 >Date: Sun, 28 Mar 2004 14:11:03 +0200 > >Dear all, > >We've got a new release! Given we find no showstoppers during the next week >we will approach the Project Management Committee (PMC) of the >db.apache.org project to get approval to relabel this release as the final >1.0 version. > >Armin worked hard to get our regression testbed rocksolid. We now have more >than 600 testcases covering all major areas of the framework! >I'm confident that this testsuite will help us to maintain and even increse >the reliability of our code from release to release. > >Thanks to all who helped and contributed to this release! > >--Thomas > > >From the release notes: > >- >Release 1.0 rc6 >- > >NEW FEATURES: > - > >NOTES: >- Repository.dtd has changed, don't forget to replace this file >- Upgraded to the new Apache License, Version 2.0 >- No support for HSQLDB 1.7.2RC1 yet >- No support for Torque 3.1 yet > >- Add new PersistenceBrokerFactory implementation for use in managed >environments when *only* the >PB-api was used and participation in JTA transaction via Synchronization >interface is needed. > >- Add new configuration property 'autoSync' to ObjectCacheDefaultImpl. Used >to enable a simple >synchronization mechanism to keep cache in sync with DB > >- Add new attribute values for reference-/collection-descriptor >auto-update/-delete attribute. >Now we have five possible values: none, link, object, true, false. The >true, false values >are now deprecated but will NOT be removed in near future (so don't >panic!). > >CHANGES: >- fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was INTEGER >but >needs BIGINT to support Long on java side > >- no longer throw an exception when calling abortTransaction more than one >time >or an internal rollback (by ConnectionManager on the used connection) was >already done > >- Add object-cache tag in standard jdbc-connection-descriptor in >repository_database.xml >to enable new 'autoSync' property of ObjectCacheDefaultImpl for all >operations made by >this DB connection > >- Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl >(handle with care ;-)) > >- odmg-api implementation, disable restore of transient objects on >transaction abort, >because we can't really restore the whole object with all references > >- now using ANTLR 2.7.2 and Unicode support in OQL queries >- now using ANT 1.6.0 > >- RelationshipPrefetcher no longer modifies auto-retrieve setting of >Relationship-Descriptor. >This may result in additional sql-queries but is safer in a multi-threaded >environment. > >- Added column methods to Criteria. addColumnEqualTo, addColumnIn etc. The >column parameter >of these methods will not be translated during sql-generation. These >methods are mainly used >for internal purpose. > >BUG FIXES: > >Please refer to our Bug tracking site >(http://issues.apache.org/scarab/servlet/scarab/) >under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx >to see details for a bug with id OJBxxx. > >- fix bug in MetadataManager, when 'per thread changes' is ena
1:0..1 mappings and dynamic proxies (was Re: [ann] new release 1.0.RC6)
Still with problems when using a 1:0..1 mapping + proxy="dynamic".
The problem is:
when making a reference between two objects (X:Y) and there can be 0 or
1 object in Y side, Y must resturn NULL if it don't exists in database,
and the object itself if there is 1 object in database. The rule is
maintained using same PK for two tables, a foreign key to guarantee data
integrity, and a NULL allowed in the X side to allow 0 values in Y side.
the error is seen when using "proxy='dynamic'" because OJB set,
internally, the value to a dynamic proxy. In the code, when you test
"myXobject.getY()==null" the result is always false, because getY is
returnin a non-materialized proxy. The following code will always throw
NPE when are 0 Y objects for a X object (but if proxy="false", there is
no error):
if(myXobject.getY()!=null) {
// It always get into here, even when there is no Y value!!!
System.out.println(myXobject.getY().getId());
// the previous line will throw NPE, because when acessisng getId(),
OJB will try to materialize,
// since there is no Y object, will try to execute getId() over a null
materialized.
}
This sayid, I think OJB should execute a count when using a reference as
proxy, and when there is 0 object, return null, not a unmaterialized
proxy (so the null test in code above will have same behaviour as if
it's not proxy).
What you say?
Best regards,
Edson Richter
Best regards,
Edson Richter
Armin Waibel wrote:
Hi Edson,
[EMAIL PROTECTED] wrote:
Hmmm, what about the "1:0..1 and proxies test for null is always
false" and the "afterStore
not being called for collections"? Are they fixed too?
Sorry I don't know. While refactoring the handling of the auto-xxx
code I do my best, but I don't turn my attention to these problems.
Could you review/test the rc6/CVS code and repost the problematic spots?
regards,
Armin
Best regards,
Edson Richter
Dear all,
We've got a new release! Given we find no showstoppers during the next
week we will approach the Project Management Committee (PMC) of the
db.apache.org project to get approval to relabel this release as the
final 1.0 version.
Armin worked hard to get our regression testbed rocksolid. We now have
more than 600 testcases covering all major areas of the framework!
I'm confident that this testsuite will help us to maintain and even
increse the reliability of our code from release to release.
Thanks to all who helped and contributed to this release!
--Thomas
From the release notes:
-
Release 1.0 rc6
-
NEW FEATURES:
-
NOTES:
- Repository.dtd has changed, don't forget to replace this file
- Upgraded to the new Apache License, Version 2.0
- No support for HSQLDB 1.7.2RC1 yet
- No support for Torque 3.1 yet
- Add new PersistenceBrokerFactory implementation for use in managed
environments when *only* the
PB-api was used and participation in JTA transaction via
Synchronization
interface is needed.
- Add new configuration property 'autoSync' to ObjectCacheDefaultImpl.
Used to enable a simple
synchronization mechanism to keep cache in sync with DB
- Add new attribute values for reference-/collection-descriptor
auto-update/-delete attribute.
Now we have five possible values: none, link, object, true, false. The
true, false values
are now deprecated but will NOT be removed in near future (so don't
panic!).
CHANGES:
- fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was
INTEGER but
needs BIGINT to support Long on java side
- no longer throw an exception when calling abortTransaction more than
one time
or an internal rollback (by ConnectionManager on the used connection)
was already done
- Add object-cache tag in standard jdbc-connection-descriptor in
repository_database.xml
to enable new 'autoSync' property of ObjectCacheDefaultImpl for all
operations made by
this DB connection
- Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl
(handle with care ;-))
- odmg-api implementation, disable restore of transient objects on
transaction abort,
because we can't really restore the whole object with all references
- now using ANTLR 2.7.2 and Unicode support in OQL queries
- now using ANT 1.6.0
- RelationshipPrefetcher no longer modifies auto-retrieve setting of
Relationship-Descriptor.
This may result in additional sql-queries but is safer in a
multi-threaded environment.
- Added column methods to Criteria. addColumnEqualTo, addColumnIn etc.
The column parameter
of these methods will not be translated during sql-generation. These
methods are mainly used
for internal purpose.
BUG FIXES:
Please refer to our Bug tracking site
(http://issues.apache.org/scarab/servlet/scarab/)
under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx
to see details for a bug with id OJBxxx.
- fix bug in MetadataManager, when 'per thread changes' is enabled and
many different
DescriptorRepo
Re: [ann] new release 1.0.RC6
If you can download sources, you could do a "bin\build jar-debug" that will generate the debugabble version. Richter Glenn Barnard wrote: Congratulations!!! I have a couple of questions... First, will it have a debuggable version? rc5 didn't (at least as far as I could see)? McCaffrey, John G. <[EMAIL PROTECTED]> and I have been working with OJB to get the primary key from a native sequence manager. John's using DB2 and I'm using MS SQL Server. Seems like John's solution works, but mine isn't (yet). When can we get our solutions included with the base code? From: Thomas Mahler <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: OJB Developers List <[EMAIL PROTECTED]>, OJB Users List <[EMAIL PROTECTED]> Subject: [ann] new release 1.0.RC6 Date: Sun, 28 Mar 2004 14:11:03 +0200 Dear all, We've got a new release! Given we find no showstoppers during the next week we will approach the Project Management Committee (PMC) of the db.apache.org project to get approval to relabel this release as the final 1.0 version. Armin worked hard to get our regression testbed rocksolid. We now have more than 600 testcases covering all major areas of the framework! I'm confident that this testsuite will help us to maintain and even increse the reliability of our code from release to release. Thanks to all who helped and contributed to this release! --Thomas From the release notes: - Release 1.0 rc6 - NEW FEATURES: - NOTES: - Repository.dtd has changed, don't forget to replace this file - Upgraded to the new Apache License, Version 2.0 - No support for HSQLDB 1.7.2RC1 yet - No support for Torque 3.1 yet - Add new PersistenceBrokerFactory implementation for use in managed environments when *only* the PB-api was used and participation in JTA transaction via Synchronization interface is needed. - Add new configuration property 'autoSync' to ObjectCacheDefaultImpl. Used to enable a simple synchronization mechanism to keep cache in sync with DB - Add new attribute values for reference-/collection-descriptor auto-update/-delete attribute. Now we have five possible values: none, link, object, true, false. The true, false values are now deprecated but will NOT be removed in near future (so don't panic!). CHANGES: - fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was INTEGER but needs BIGINT to support Long on java side - no longer throw an exception when calling abortTransaction more than one time or an internal rollback (by ConnectionManager on the used connection) was already done - Add object-cache tag in standard jdbc-connection-descriptor in repository_database.xml to enable new 'autoSync' property of ObjectCacheDefaultImpl for all operations made by this DB connection - Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl (handle with care ;-)) - odmg-api implementation, disable restore of transient objects on transaction abort, because we can't really restore the whole object with all references - now using ANTLR 2.7.2 and Unicode support in OQL queries - now using ANT 1.6.0 - RelationshipPrefetcher no longer modifies auto-retrieve setting of Relationship-Descriptor. This may result in additional sql-queries but is safer in a multi-threaded environment. - Added column methods to Criteria. addColumnEqualTo, addColumnIn etc. The column parameter of these methods will not be translated during sql-generation. These methods are mainly used for internal purpose. BUG FIXES: Please refer to our Bug tracking site (http://issues.apache.org/scarab/servlet/scarab/) under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx to see details for a bug with id OJBxxx. - fix bug in MetadataManager, when 'per thread changes' is enabled and many different DescriptorRepository instances were used, gc can't collect unused instances because StatementManager doesn't release references to used DescriptorRepository instances. - fix bug in ObjectCacheDefaultImpl, it doesn't make sense to use a soft reference for the object wrapper of the cached object. Use a softreference for the cached object instead - fix bug in CacheDistributor (internal used ObjectCache implementation), each CacheDistributor instance have to held ObjectCache instances for the associated PersistenceBroker instance - fix documentation bug in ObjectCacheDefaultImpl, property 'timeout' use seconds instead of milliseconds - fix bug in new DList implementation (DListImpl_2), materialization of objects failed when DList instance itself was persisted (using db.bind(...)) and re-loaded within tx, but iteration over the list values was done outside of the tx - The bogus ODMG Distributed Lockmanagement feature has been replaced by a new Servlet based LockServer. Transaction isolation should now work properly even accross a cluster of JVMs. - fix bug in
RE: [ann] new release 1.0.RC6
Congratulations!!! I have a couple of questions... First, will it have a debuggable version? rc5 didn't (at least as far as I could see)? McCaffrey, John G. <[EMAIL PROTECTED]> and I have been working with OJB to get the primary key from a native sequence manager. John's using DB2 and I'm using MS SQL Server. Seems like John's solution works, but mine isn't (yet). When can we get our solutions included with the base code? From: Thomas Mahler <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: OJB Developers List <[EMAIL PROTECTED]>, OJB Users List <[EMAIL PROTECTED]> Subject: [ann] new release 1.0.RC6 Date: Sun, 28 Mar 2004 14:11:03 +0200 Dear all, We've got a new release! Given we find no showstoppers during the next week we will approach the Project Management Committee (PMC) of the db.apache.org project to get approval to relabel this release as the final 1.0 version. Armin worked hard to get our regression testbed rocksolid. We now have more than 600 testcases covering all major areas of the framework! I'm confident that this testsuite will help us to maintain and even increse the reliability of our code from release to release. Thanks to all who helped and contributed to this release! --Thomas From the release notes: - Release 1.0 rc6 - NEW FEATURES: - NOTES: - Repository.dtd has changed, don't forget to replace this file - Upgraded to the new Apache License, Version 2.0 - No support for HSQLDB 1.7.2RC1 yet - No support for Torque 3.1 yet - Add new PersistenceBrokerFactory implementation for use in managed environments when *only* the PB-api was used and participation in JTA transaction via Synchronization interface is needed. - Add new configuration property 'autoSync' to ObjectCacheDefaultImpl. Used to enable a simple synchronization mechanism to keep cache in sync with DB - Add new attribute values for reference-/collection-descriptor auto-update/-delete attribute. Now we have five possible values: none, link, object, true, false. The true, false values are now deprecated but will NOT be removed in near future (so don't panic!). CHANGES: - fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was INTEGER but needs BIGINT to support Long on java side - no longer throw an exception when calling abortTransaction more than one time or an internal rollback (by ConnectionManager on the used connection) was already done - Add object-cache tag in standard jdbc-connection-descriptor in repository_database.xml to enable new 'autoSync' property of ObjectCacheDefaultImpl for all operations made by this DB connection - Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl (handle with care ;-)) - odmg-api implementation, disable restore of transient objects on transaction abort, because we can't really restore the whole object with all references - now using ANTLR 2.7.2 and Unicode support in OQL queries - now using ANT 1.6.0 - RelationshipPrefetcher no longer modifies auto-retrieve setting of Relationship-Descriptor. This may result in additional sql-queries but is safer in a multi-threaded environment. - Added column methods to Criteria. addColumnEqualTo, addColumnIn etc. The column parameter of these methods will not be translated during sql-generation. These methods are mainly used for internal purpose. BUG FIXES: Please refer to our Bug tracking site (http://issues.apache.org/scarab/servlet/scarab/) under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx to see details for a bug with id OJBxxx. - fix bug in MetadataManager, when 'per thread changes' is enabled and many different DescriptorRepository instances were used, gc can't collect unused instances because StatementManager doesn't release references to used DescriptorRepository instances. - fix bug in ObjectCacheDefaultImpl, it doesn't make sense to use a soft reference for the object wrapper of the cached object. Use a softreference for the cached object instead - fix bug in CacheDistributor (internal used ObjectCache implementation), each CacheDistributor instance have to held ObjectCache instances for the associated PersistenceBroker instance - fix documentation bug in ObjectCacheDefaultImpl, property 'timeout' use seconds instead of milliseconds - fix bug in new DList implementation (DListImpl_2), materialization of objects failed when DList instance itself was persisted (using db.bind(...)) and re-loaded within tx, but iteration over the list values was done outside of the tx - The bogus ODMG Distributed Lockmanagement feature has been replaced by a new Servlet based LockServer. Transaction isolation should now work properly even accross a cluster of JVMs. - fix bug in MtoNCollectionPrefetcher, multi-key handling is now supported. - ClassCastException with ManageableCollection implementations on m:n rela
Re: [ann] new release 1.0.RC6
Appear the afterStore stuff is in place, and operational (so, RemovalAwareXXX again working fine). Sorry if sometimes I'm so fast in reporting problems, but I tryied to keep our project tuned to latest OJB ever (maybe not best policy, but until today solved most our problems with bugs). Sometime this policy lend us to use a CVS Head that may be not complete, and areas with work-in-progress (like the afterXXX stuff) may be in "pending changes" state... Thanks. Armin Waibel wrote: Hi Edson, [EMAIL PROTECTED] wrote: Hmmm, what about the "1:0..1 and proxies test for null is always false" and the "afterStore not being called for collections"? Are they fixed too? Sorry I don't know. While refactoring the handling of the auto-xxx code I do my best, but I don't turn my attention to these problems. Could you review/test the rc6/CVS code and repost the problematic spots? regards, Armin Best regards, Edson Richter Dear all, We've got a new release! Given we find no showstoppers during the next week we will approach the Project Management Committee (PMC) of the db.apache.org project to get approval to relabel this release as the final 1.0 version. Armin worked hard to get our regression testbed rocksolid. We now have more than 600 testcases covering all major areas of the framework! I'm confident that this testsuite will help us to maintain and even increse the reliability of our code from release to release. Thanks to all who helped and contributed to this release! --Thomas From the release notes: - Release 1.0 rc6 - NEW FEATURES: - NOTES: - Repository.dtd has changed, don't forget to replace this file - Upgraded to the new Apache License, Version 2.0 - No support for HSQLDB 1.7.2RC1 yet - No support for Torque 3.1 yet - Add new PersistenceBrokerFactory implementation for use in managed environments when *only* the PB-api was used and participation in JTA transaction via Synchronization interface is needed. - Add new configuration property 'autoSync' to ObjectCacheDefaultImpl. Used to enable a simple synchronization mechanism to keep cache in sync with DB - Add new attribute values for reference-/collection-descriptor auto-update/-delete attribute. Now we have five possible values: none, link, object, true, false. The true, false values are now deprecated but will NOT be removed in near future (so don't panic!). CHANGES: - fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was INTEGER but needs BIGINT to support Long on java side - no longer throw an exception when calling abortTransaction more than one time or an internal rollback (by ConnectionManager on the used connection) was already done - Add object-cache tag in standard jdbc-connection-descriptor in repository_database.xml to enable new 'autoSync' property of ObjectCacheDefaultImpl for all operations made by this DB connection - Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl (handle with care ;-)) - odmg-api implementation, disable restore of transient objects on transaction abort, because we can't really restore the whole object with all references - now using ANTLR 2.7.2 and Unicode support in OQL queries - now using ANT 1.6.0 - RelationshipPrefetcher no longer modifies auto-retrieve setting of Relationship-Descriptor. This may result in additional sql-queries but is safer in a multi-threaded environment. - Added column methods to Criteria. addColumnEqualTo, addColumnIn etc. The column parameter of these methods will not be translated during sql-generation. These methods are mainly used for internal purpose. BUG FIXES: Please refer to our Bug tracking site (http://issues.apache.org/scarab/servlet/scarab/) under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx to see details for a bug with id OJBxxx. - fix bug in MetadataManager, when 'per thread changes' is enabled and many different DescriptorRepository instances were used, gc can't collect unused instances because StatementManager doesn't release references to used DescriptorRepository instances. - fix bug in ObjectCacheDefaultImpl, it doesn't make sense to use a soft reference for the object wrapper of the cached object. Use a softreference for the cached object instead - fix bug in CacheDistributor (internal used ObjectCache implementation), each CacheDistributor instance have to held ObjectCache instances for the associated PersistenceBroker instance - fix documentation bug in ObjectCacheDefaultImpl, property 'timeout' use seconds instead of milliseconds - fix bug in new DList implementation (DListImpl_2), materialization of objects failed when DList instance itself was persisted (using db.bind(...)) and re-loaded within tx, but iteration over the list values was done outside of the tx - The bogus ODMG Distributed Lockmanagement feature has been replaced by a new Servlet based LockSe
CreationDate-Column for each Table
Hi, I have a (quite small) problem: I want that each table in my database has an attribute "CreationDate" which reflects the time when this row has been inserted. But I don't want to use any database-specific datatypes or functions. My current idea is really simple and uses the callback-mechanism: Each Java-Object gets an attribute creationDate which I can set to the correct value in the PeristenceBrokerAware.beforeInsert(PersistenceBroker) method. But with this approach I have one problem, how could I set the creationDate-values to the rows of N-M-Relations which I have not decomposed? Is there a way to extend the "inserts" of OJB, when OJB is creating those rows? Glad for any help! Tino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ann] new release 1.0.RC6
Hi Edson, [EMAIL PROTECTED] wrote: Hmmm, what about the "1:0..1 and proxies test for null is always false" and the "afterStore not being called for collections"? Are they fixed too? Sorry I don't know. While refactoring the handling of the auto-xxx code I do my best, but I don't turn my attention to these problems. Could you review/test the rc6/CVS code and repost the problematic spots? regards, Armin Best regards, Edson Richter Dear all, We've got a new release! Given we find no showstoppers during the next week we will approach the Project Management Committee (PMC) of the db.apache.org project to get approval to relabel this release as the final 1.0 version. Armin worked hard to get our regression testbed rocksolid. We now have more than 600 testcases covering all major areas of the framework! I'm confident that this testsuite will help us to maintain and even increse the reliability of our code from release to release. Thanks to all who helped and contributed to this release! --Thomas From the release notes: - Release 1.0 rc6 - NEW FEATURES: - NOTES: - Repository.dtd has changed, don't forget to replace this file - Upgraded to the new Apache License, Version 2.0 - No support for HSQLDB 1.7.2RC1 yet - No support for Torque 3.1 yet - Add new PersistenceBrokerFactory implementation for use in managed environments when *only* the PB-api was used and participation in JTA transaction via Synchronization interface is needed. - Add new configuration property 'autoSync' to ObjectCacheDefaultImpl. Used to enable a simple synchronization mechanism to keep cache in sync with DB - Add new attribute values for reference-/collection-descriptor auto-update/-delete attribute. Now we have five possible values: none, link, object, true, false. The true, false values are now deprecated but will NOT be removed in near future (so don't panic!). CHANGES: - fix bug in internal table OJB_HL_SEQ, column type of MAX_ID was INTEGER but needs BIGINT to support Long on java side - no longer throw an exception when calling abortTransaction more than one time or an internal rollback (by ConnectionManager on the used connection) was already done - Add object-cache tag in standard jdbc-connection-descriptor in repository_database.xml to enable new 'autoSync' property of ObjectCacheDefaultImpl for all operations made by this DB connection - Allow infinite lifetime of cached objects in ObjectCacheDefaultImpl (handle with care ;-)) - odmg-api implementation, disable restore of transient objects on transaction abort, because we can't really restore the whole object with all references - now using ANTLR 2.7.2 and Unicode support in OQL queries - now using ANT 1.6.0 - RelationshipPrefetcher no longer modifies auto-retrieve setting of Relationship-Descriptor. This may result in additional sql-queries but is safer in a multi-threaded environment. - Added column methods to Criteria. addColumnEqualTo, addColumnIn etc. The column parameter of these methods will not be translated during sql-generation. These methods are mainly used for internal purpose. BUG FIXES: Please refer to our Bug tracking site (http://issues.apache.org/scarab/servlet/scarab/) under http://issues.apache.org/scarab/servlet/scarab/issues/id/OJBxxx to see details for a bug with id OJBxxx. - fix bug in MetadataManager, when 'per thread changes' is enabled and many different DescriptorRepository instances were used, gc can't collect unused instances because StatementManager doesn't release references to used DescriptorRepository instances. - fix bug in ObjectCacheDefaultImpl, it doesn't make sense to use a soft reference for the object wrapper of the cached object. Use a softreference for the cached object instead - fix bug in CacheDistributor (internal used ObjectCache implementation), each CacheDistributor instance have to held ObjectCache instances for the associated PersistenceBroker instance - fix documentation bug in ObjectCacheDefaultImpl, property 'timeout' use seconds instead of milliseconds - fix bug in new DList implementation (DListImpl_2), materialization of objects failed when DList instance itself was persisted (using db.bind(...)) and re-loaded within tx, but iteration over the list values was done outside of the tx - The bogus ODMG Distributed Lockmanagement feature has been replaced by a new Servlet based LockServer. Transaction isolation should now work properly even accross a cluster of JVMs. - fix bug in MtoNCollectionPrefetcher, multi-key handling is now supported. - ClassCastException with ManageableCollection implementations on m:n relation. m:n relation now can handle ManageableCollection collection classes in a correct way, the collection class no longer needs to implement java.util.Collection. KNOWN ISSUES: - odmg-api: It is not possible to exchange objects in 1:n references. E.g. two objects with 1:
Re: OJB with distributed tx and BMT
Hi Francesco, Francesco Russo wrote: Hi Thomas, let's suppose I want to use OJB with distributed BMT. In such a scenario, I guess I should do something like: //* a generic SessionBean's method ... UserTransaction utx = sessionCtx.getUserTransaction(); utx.begin(); //* acquire transactional resources which will be enlisted in the current transaction //* these resources will be XAResources according to the XOpen/XA standard specification ... do work utx.commit(); ... So, I am wondering how does OJB integrates itself in such a scenario. > OJB needs some specific configuration properties settings for use in managed environments. Here you can find an example for JBoss integration (docs are valid for rc6 or CVS) http://db.apache.org/ojb/deployment.html#Deployment%20in%20EJB%20based%20applications The integration in other J2EE compatible appServer are similar. Currently PB- and the ODMG-api are supported in managed environments. Which OJB classes can support me in coding something like that? I have downloaded your sources, but all the examples were involved with Container Managed Persistence, so I thought it was simply not possible to achieve distriuted BMT with OJB. This should be no problem. PB-api: UserTransaction utx = sessionCtx.getUserTransaction(); utx.begin(); PersistenceBroker broker = PersistenceBrokerFactory.create... // do work utx.commit(); ODMG-api: UserTransaction utx = sessionCtx.getUserTransaction(); utx.begin(); Transaction tx = odmg.currentTransaction(); // do work utx.commit(); As in my previous mail, I repeat: I am a newbie to OJB, so maybe I am just missing something, but I need you to prove that I am wrong, for example pointing me out the classes I should better study and investigate to fully understand that I am really wrong. No, you are right. All examples using cm-tx. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Loss of precsion with PersistenceBroker.store() and BigDecima l on Sybase.
Hi Stuart/Danilo
I don't use Sybase ASA or Sybase ASE, so it's hard to decide which way
to go. Can someone say what we should change in
PlatformSybaseImpl (Sybase base class)
PlatformSybaseASAImpl
PlatformSybaseASEImpl
classes to make OJB proper work with Sybase?
Does Sybase support NUMERIC (is mapped to BigDecimal too) type?
public void setObjectForStatement(PreparedStatement ps, int index,
Object value, int sqlType) throws SQLException
{
// Stuart's patch
if (sqlType == Types.DECIMAL)
{
ps.setObject(index, value);
}
else
{
super.setObjectForStatement(ps, index, value, sqlType);
}
}
regards,
Armin
Stuart Heriot wrote:
Hi Danilo,
Can't say I have much confidence in Sybase providing a permanent solution
given your experience. We'll stick with the OJB fix for now. The
ps.setBigDecimal() works also.
Cheers
Stuart
-Original Message-
From: Danilo Tommasina [mailto:[EMAIL PROTECTED]
Sent: Friday, 26 March 2004 11:41 PM
To: OJB Users List
Subject: Re: Loss of precsion with PersistenceBroker.store() and
BigDecima l on Sybase.
Hi,
We have the same problem with Sybase, the bug seems not to be really an
OJB problem it is a bug in the JDBC dirver, however doing a special
handling for BigDecimal in OJB may be a good workaround.
The bug appears in several releases of the Sybase drivers and appears
and disappears in different builds of the same driver version.
Driver file jconn2_v55_B25089.jar (also version 5.5 Build 25089) works
correctly for us. In the following release build, the bug is still
present. For some reason the bug seems to be fixed and reappear in new
driver releases on a regular basis, this is very annoying since we do
not always have the control over wich driver releases our customer are
using :(
Probably using a ps.setBigDecimal(...) call (instead of
ps.setObject(...) ) if sqlType is equal to BIG_DECIMAL would solve the
problem.
cheers
danilo
Hi Stuart,
do we need this patch for both Sybase versions (Sybase ASA, Sybase ASE)?
regards,
Armin
Stuart Heriot wrote:
I have implemented a fix for this issue locally by modifying the Sybase
Plaform dependant class (see below). I picked this up from a posting
about a
similar issue with DB2. The DB2 fix, however, is not in the rc5
release. We
need a fix to be included in the official OJB release so that we don't
reintroduce this problem when implementing future releases of OJB. Is
this
possible? Please advise..
Regards Stuart Heriot
package org.apache.ojb.broker.platforms;
public class PlatformSybaseASEImpl extends PlatformDefaultImpl {
/**
* Platform specific fix to BigDecimal's being truncated when stored
to Sybase db.
*/
public void setObjectForStatement(PreparedStatement ps, int index,
Object value, int sqlType) throws SQLException {
// Added code to fix problem with truncation occuring on
// BigDecimals when setObject is used in PlatformDefaultImpl
// Copied from similar fix to DB2 implementation.
if (sqlType == Types.DECIMAL) {
ps.setObject(index, value);
} else {
super.setObjectForStatement(ps, index, value,
sqlType);
}
}
/**
* Get join syntax type for this RDBMS * one on of the
constants from JoinSyntaxType interface
*/
public byte getJoinSyntaxType() {
return SYBASE_JOIN_SYNTAX;
}
}
-Original Message-
From: Stuart Heriot [mailto:[EMAIL PROTECTED]
Sent: Friday, 26 March 2004 9:34 AM
To: 'OJB Users List'
Subject: Loss of precsion with PersistenceBroker.store() and BigDecimal
on Sybase.
Hi,
We have come across a problem storing BigDecimals with values being
truncated and all decimal places being set to zero. Our system has a
number
of value types stored with 2, 4 or 6 decimal point precision. We are
using
BigDecimals rather than floats or doubles to maintain accuracy in
financial
calculations within our application. Repository mapping has JDBC-TYPE
set to
DECIMAL and precision set as required. Old values in the database are
retrieved Ok with the correct precision but new values we try and
store are
all truncated.
I came across a posting some months ago about a similar problem with
DB2 and
using prepared statements. Is there a fix for this?
Currently using OJB rc5 and a Sybase 12.5 database.
Thanks in advance...
Stuart Heriot
-
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 with distributed tx and BMT
Hi Thomas, let's suppose I want to use OJB with distributed BMT. In such a scenario, I guess I should do something like: //* a generic SessionBean's method ... UserTransaction utx = sessionCtx.getUserTransaction(); utx.begin(); //* acquire transactional resources which will be enlisted in the current transaction //* these resources will be XAResources according to the XOpen/XA standard specification ... do work utx.commit(); ... So, I am wondering how does OJB integrates itself in such a scenario. Which OJB classes can support me in coding something like that? I have downloaded your sources, but all the examples were involved with Container Managed Persistence, so I thought it was simply not possible to achieve distriuted BMT with OJB. As in my previous mail, I repeat: I am a newbie to OJB, so maybe I am just missing something, but I need you to prove that I am wrong, for example pointing me out the classes I should better study and investigate to fully understand that I am really wrong. -- __ Francesco Russo DLAB - Datawarehouse Laboratory CINECA - Interuniversitary Computing Centre via Magnanelli, 6/3 40033 Casalecchio di Reno (Bologna) - ITALY e-mail: [EMAIL PROTECTED] Thomas Mahler wrote: Hi Francesco, OJB provides support for JTA integration, so you should be able to use it in distributed BMT (and also CMT) environments. Our JTA Mechanism works well with several J2EE containers and also Non J2EE-JTA implementation (as some CORBA ORB's with TransactionServer implementation) I don't quite understand why you are talking about JCA in this context? JCA is not needed to work with distributed transactions. Please read http://db.apache.org/ojb/deployment.html for more details. Thomas Francesco Russo wrote: Hi everybody, I was wondering whether OJB could be used in a managed enviroinment with distributed BMTs (Bean Managed Transactions) or not. In order to find an answer to my doubts, I downloaded the srcs and started to look for some useful clues and I didn't find anything stating the above scenario can be implemented, rather a hint that made me think it was not yet implemented (but planned for the future?). That's what I found: since, if I am not wrong, it is required to acquire a ManagedConnection from the Application Server implementation of the javax.resource.spi.ConnectionManager via a call to the allocateConnection(..., ...) method, I have searched for this call in the OJB srcs. As a result I got that the above call is issued only in two classes: 1. org.apache.ojb.otm.connector.JCAKit 2. org.apache.ojb.otm.connector.OTMConnectionManager The former class calls the allocateConnection method over the latter one, so this entails that OJB provdes its own implementation of the javax.resource.spi.ConnectionManager, behaviour that is common to all those cases in which the application is outside a managed environment. Question 1: why not relaying on the Application Server implementation of the ConnectionManager? Furtheron, the javax.resource.spi.ManagedConnection returned as an org.apache.ojb.otm.connector.OTMJCAManagedConnection does not support the getXAResource() method, which is needed for enlisting the connections currently used by an application into the transactional context handled by the external TransactionManager according to the XOpen/XA Specification. As I stated before, all these things made me think it is not possible to use BMTs along with OJB in managed environmet with distributed transaction, but possibily I'm just missing something, that's why I'm asking your help. Any comments are appreciated - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Francesco Russo DLAB - Datawarehouse Laboratory CINECA - Interuniversitary Computing Centre via Magnanelli, 6/3 40033 Casalecchio di Reno (Bologna) - ITALY e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ERRATA CORRIGE - Re: OJB with distributed tx and BMT
Sorry for duplicating my post, but I made a mistake typing "Container Managed Persistence" instead of "Container Managed Transaction"! Hi Thomas, let's suppose I want to use OJB with distributed BMT. In such a scenario, I guess I should do something like: //* a generic SessionBean's method ... UserTransaction utx = sessionCtx.getUserTransaction(); utx.begin(); //* acquire transactional resources which will be enlisted in the current transaction //* these resources will be XAResources according to the XOpen/XA standard specification ... do work utx.commit(); ... So, I am wondering how does OJB integrates itself in such a scenario. Which OJB classes can support me in coding something like that? I have downloaded your sources, but all the examples were involved with Container Managed Transaction, so I thought it was simply not possible to achieve distriuted BMT with OJB. As in my previous mail, I repeat: I am a newbie to OJB, so maybe I am just missing something, but I need you to prove that I am wrong, for example pointing me out the classes I should better study and investigate to fully understand that I am really wrong. -- __ Francesco Russo DLAB - Datawarehouse Laboratory CINECA - Interuniversitary Computing Centre via Magnanelli, 6/3 40033 Casalecchio di Reno (Bologna) - ITALY e-mail: [EMAIL PROTECTED] Thomas Mahler wrote: Hi Francesco, OJB provides support for JTA integration, so you should be able to use it in distributed BMT (and also CMT) environments. Our JTA Mechanism works well with several J2EE containers and also Non J2EE-JTA implementation (as some CORBA ORB's with TransactionServer implementation) I don't quite understand why you are talking about JCA in this context? JCA is not needed to work with distributed transactions. Please read http://db.apache.org/ojb/deployment.html for more details. Thomas Francesco Russo wrote: Hi everybody, I was wondering whether OJB could be used in a managed enviroinment with distributed BMTs (Bean Managed Transactions) or not. In order to find an answer to my doubts, I downloaded the srcs and started to look for some useful clues and I didn't find anything stating the above scenario can be implemented, rather a hint that made me think it was not yet implemented (but planned for the future?). That's what I found: since, if I am not wrong, it is required to acquire a ManagedConnection from the Application Server implementation of the javax.resource.spi.ConnectionManager via a call to the allocateConnection(..., ...) method, I have searched for this call in the OJB srcs. As a result I got that the above call is issued only in two classes: 1. org.apache.ojb.otm.connector.JCAKit 2. org.apache.ojb.otm.connector.OTMConnectionManager The former class calls the allocateConnection method over the latter one, so this entails that OJB provdes its own implementation of the javax.resource.spi.ConnectionManager, behaviour that is common to all those cases in which the application is outside a managed environment. Question 1: why not relaying on the Application Server implementation of the ConnectionManager? Furtheron, the javax.resource.spi.ManagedConnection returned as an org.apache.ojb.otm.connector.OTMJCAManagedConnection does not support the getXAResource() method, which is needed for enlisting the connections currently used by an application into the transactional context handled by the external TransactionManager according to the XOpen/XA Specification. As I stated before, all these things made me think it is not possible to use BMTs along with OJB in managed environmet with distributed transaction, but possibily I'm just missing something, that's why I'm asking your help. Any comments are appreciated - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Francesco Russo DLAB - Datawarehouse Laboratory CINECA - Interuniversitary Computing Centre via Magnanelli, 6/3 40033 Casalecchio di Reno (Bologna) - ITALY e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: repository.xml in a jar
Hi, we have similar Problems when copying data from one db to another. You could use the same include mechanism ojb is using i.e. &user.xml to point to a "custom" xml in the file system. You'd just have to include an empty file with your code. Otherwise you could also modify the ojb repository at run-time, there is some kind of interface to it. You'd then just have your own property files to control the behaviour. Cheers, Stefan Charles N. Harvey III wrote: Hello. I am trying to build an interface to a particular database and package it all up in a jar. Then have this jar included in other applications. The thing is, I want to keep the OJB.properties and repository.xml inside the jar, since it does not change. If the application that will house this jar has mappings of its own, how do I make OJB see both sets of configurations? Is there way to do this? Can I give repositoryFile multiple xml files: # # repository file settings # # The repositoryFile entry tells OJB to use this file as as its standard # mapping repository. The file is looked up from the classpath. # repositoryFile = repository.xml, repository-ldap.xml # Or, should I create a properties file with a different name, OJB-LDAP.properties and then have that call repository-ldap.xml? Then I would have to set a system property telling OJB where to find the new properties file, but wouldn't that then make OJB not see the original one? Yes, my head is spinning over this one. And I haven't even asked about the LDAP stuff yet. ;) Found a free jar on Novell that makes any LDAP server look like a relational database, so I can use OJB!! Any tips are welcomed. Thanks a lot. Charlie - 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]
