Default persistence broker error after session died

[Hernan Gustavo Bertagni]

Hello all,

I've inherited an application made by others, and it uses OJB (1.0) to access the 
database (an Oracle 9i).

I'm having a problem with the persistence broker. The application gets
the broker using the PersistenceBrokerFactory.defaultPersistenceBroker()
and it works well most of the time. My problem is when a class is
modified and the active sessions die. After that, when I try to get the
default persistence broker I get the following error, and only when I
restart the project I'm able to access the broker again.

The error goes:

[3/31/04 15:12:09:488 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:498 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.broker.cache.ObjectCacheDefaultImpl" does not implement the
interface org.apache.ojb.broker.cache.ObjectCache, which is a requirement for the key 
"ObjectCacheClass". Using default class
org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
[3/31/04 15:12:09:558 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:759 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl" does not
implement the interface org.apache.ojb.broker.accesslayer.ConnectionFactory, which is 
a requirement for the key "ConnectionFactoryClass". Using
default class org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
[3/31/04 15:12:09:769 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:769 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.odmg.locking.LockManagerDefaultImpl" does not implement the
interface org.apache.ojb.odmg.locking.LockManager, which is a requirement for the key 
"LockManagerClass". Using default class
org.apache.ojb.odmg.locking.LockManagerDefaultImpl
[3/31/04 15:12:09:809 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:809 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.odmg.locking.InMemoryLockMapImpl" does not implement the
interface org.apache.ojb.odmg.locking.LockMap, which is a requirement for the key 
"LockMapClass". Using default class
org.apache.ojb.odmg.locking.PersistentLockMapImpl
[3/31/04 15:12:09:809 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:809 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.broker.util.logging.PoorMansLoggerImpl" does not implement the
interface org.apache.ojb.broker.util.logging.Logger, which is a requirement for the 
key "LoggerClass". Using default class
org.apache.ojb.broker.util.logging.PoorMansLoggerImpl
[3/31/04 15:12:09:839 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:839 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl" does
not implement the interface 
org.apache.ojb.broker.metadata.fieldaccess.PersistentField, which is a requirement for 
the key "PersistentFieldClass".
Using default class 
org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl
[3/31/04 15:12:09:999 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:09:999 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.broker.core.PersistenceBrokerImpl" does not implement the
interface org.apache.ojb.broker.PersistenceBroker, which is a requirement for the key 
"PersistenceBrokerClass". Using default class
org.apache.ojb.broker.core.PersistenceBrokerImpl
[3/31/04 15:12:10:109 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:10:109 ART] 3c9368e1 SystemOut U The specified class 
"org.apache.ojb.odmg.collections.DListImpl" does not implement the interface
org.apache.ojb.broker.ManageableCollection, which is a requirement for the key 
"OqlCollectionClass". Using default class
org.apache.ojb.odmg.collections.DListImpl
java.lang.ClassCastException: 
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.init(Unknown 
Source)
at org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory.(Unknown 
Source)
at 
org.apache.ojb.broker.PersistenceBrokerFactory.defaultPersistenceBroker(Unknown Source)
at com.rio.gec.cliente.servlets.GestionClientes.doGet(GestionClientes.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
com.ibm.servlet.engine.webapp.StrictServletInstance.doService(ServletManager.java:827)
[3/31/04 15:12:10:169 ART] 3c9368e1 SystemOut U [BOOT] ERROR: 
[3/31/04 15:12:10:169 ART] 3c9368e1 SystemOut U Error in instantiation of 
PersistenceBrokerFactory class class
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl, try to use default 
PersistenceBrokerFactory implementation
[3/31/04 15:12:10:169 ART] 3c9368e1 SystemOut U 
org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
at 
com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(StrictLifecyc

OJB and JCS

[Guillaume Nodet]

Hi !

I'm trying to use JCS for the cache layer in 
OJB and encountered the following problem:
the hash code of the Identity object is computed 
using the hash code of the top-level class
of the real subject. The problem is that the
hashCode() method  of the Class object is not
overrident so that it depends on the internal
state of the jvm and is not the same across
different jvms.  So when serializing the Identity
object to send to JCS, the hashCode is serialized
along with the object (it is part of it for performance
reasons) and the cache is messed up, because another
jvm could have computed another hash code for the same
object.

Could the m_stringRepresentation and the m_hashCode 
attributes of the Identity class could be made transient,
so that they are not serialized with the Identity ?

Thanks,

Guillaume Nodet

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Is it platform independant if I use upper() and like '%'?

[ZZZ Liu]

Hi All,

I am using ojb as the persistence layer and assume
that I don't need to re-write my code if I need to
switch to a different database. However, if I use 

Criteria crit = new Criteria();
crit.addEqualTo("upper(firstname)", "TOM");
crit.addLike("firstname", "T%");

Is it still platform independant?

Thanks in advance for you reply.

Zhe


__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Not suppported type with set ojcect

[Ismail S. Siddiqui]

Hi,
I have currently ported data from mySQL to SQL server. I have a bean called
"Account"  and using xdeclet to generated ojb repository.
OR mapping looks just fine . I have jdbc-type INTEGER for all int fields in
database and  VARCHAR for all Varchar fields.
In my bean I have 3 java.sql.Date  fields which has DATE as jdbc-type in
repository and 2 java.sql.Timestamp  fields which has jdbc-type Timestamp.
All of these five fields have data type "datetime" at MS SQL level.

When I insert a record in this table using ojb it works fine but when I
select a record using follwong method

public Account retrieveAccountByUsername(String username) {

PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
Criteria c = new Criteria();
c.addEqualTo("user_name", username);
c.addEqualTo("active","1");
QueryByCriteria query = new QueryByCriteria(Account.class, c);
Account ac = (Account)broker.getObjectByQuery(query);
broker.commitTransaction();
broker.close();
System.out.println(ac.getLast_name());
return ac;
}
it gives the following error message

ava.sql.SQLException: Not supported type with setObject:2,java.lang.String,4
at com.inet.tds.c.setObject(Unknown Source)
at com.inet.tds.c.setObject(Unknown Source)
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement(Un
known Source)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindStatementValue(Unknow
n Source)
at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindSelectionCriteria(Unk
nown Source)
at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(Unknown
Source)
at org.apache.ojb.broker.accesslayer.StatementManager.bindStatement(Unknown
Source)
at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source)
at
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unkn
own Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(Unkn
own Source)
at
com.alloy.common.business.AccountManagement.retrieveAccountByUsername(Accoun
tManagement.java:115)
at test.AccountTest.main(AccountTest.java:17)
org.apache.ojb.broker.PersistenceBrokerException:
org.apache.ojb.broker.PersistenceBrokerSQLException: java.sql.SQLException:
Not supported type with setObject:2,java.lang.String,4
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(Unkn
own Source)
at
com.alloy.common.business.AccountManagement.retrieveAccountByUsername(Accoun
tManagement.java:115)
at test.AccountTest.main(AccountTest.java:17)
Caused by: org.apache.ojb.broker.PersistenceBrokerSQLException:
java.sql.SQLException: Not supported type with
setObject:2,java.lang.String,4
at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source)
at
org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unkn
own Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknow
n Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknow
n Source)
... 7 more
Caused by: java.sql.SQLException: Not supported type with
setObject:2,java.lang.String,4
at com.inet.tds.c.setObject(Unknown Source)
at com.inet.tds.c.setObject(Unknown Source)
at
org.ap

Issue with Iterator.hasNext() and custom RowReader

[Clute, Andrew]

As a little background, I have created a custom RowReader that allows me
to filter out objects based upon some criteria on that object. More
specifically, if a deleted date exist on the object, I filter it out and
return null.

The idea behind this is that I want to maintain some history in my
database, but not even have the filtered object available to be used
outside of OJB. The custom rowreader works pretty well in doing that,
except I have run into an issue with Iterators returned from PB, and
also internal functions inside of OJB that use these iterators.

In my application, I know that the Iterator might have a spot that
contains a null object, but the it.hasNext() will return true, because
the null object was placed into there.

However, there are places inside of OJB where the assumption has been
made that an object coming out of an Iterator will always be non-null.
This is probably not a bad assumption as you would assume this would
never be the case. But, as you can probably tell, what is happening is
the Iterator thinks it has a next value, but doesn't really know that it
doesn't until the next() method is called, and the RowReader filters it
out.

A good example of where OJB makes this assumption is in
ReferencePrefetcher.associateBatched(). But this is just one of many.


Now, I see a couple options:
1)Stop using custom RowReaders, and make it known via documentation that
a RowReader must still return a non-null objects, otherwise other code
will break
2) Fix all the points in other OJB methods where the assumption is made
that a value that comes out the Iterator is not null, and make it do a
null-check
3) Change RsIterator.next() to be smater and give the RowReader a chance
to filter out the objects. However, the problem with this is if the
'filtered' object exist in the middle of the chain, the rs.next() would
return false, and the rest of the non-filtered objects would be lost.

I would love to get some thoughts on this. My guess is that number 1 or
2 is the best answers, although 1 seems to be pretty harsh.

Thanks

-Andrew

Re: Help M-To-N relation update => deletion of referenced objects .

[Armin Waibel]

Hi Thierry,

by default OJB use a removal aware collection, but in your case you 
shouldn't use it. Thus you only need to declare the collection within 
your collection-descriptor:


 
 

regards,
Armin
Thierry Hanot wrote:

I've just tried with the last cvs version . I still have the problem . 
It seem's that the removalAware Collections should not delete objects if the
related collection is not in auto-delete="true" or auto-update="true" . 
Is somebody could help me with this ?

B.R 

Thierry 

-Original Message-
From: Thierry Hanot [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 01, 2004 7:52 PM
To: [EMAIL PROTECTED]
Subject: Help M-To-N relation update => deletion of referenced objects .

Hello  all 
 
I have a big pbm ...
 
I'm using a M-TO-N relation something like:


 name="persons"
 
collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList
"
 element-class-ref="org.apache.ojb.broker.Person"
 auto-retrieve="true"
 auto-update="false"
auto-delete="false"
 indirection-table="PERSON_PROJECT"
  >
 
 

 
 
 
My problem is when i update a project after removing some reference on some
personne the personne are deleted.
 
After looking in obj internally , i see that ojb use a
RemovalAwareCollection for keeping the personnes list in the projet. After
the collection update ( in storeCollection ) the PB call the method
afterStore in the RemovalAwareCollection . This method call delete on the
removed elements ( the referenced elements not the links ... ) .
 
I tried to used a proxy ,  i still have the problem . 
 
In fact i have the problem on all collection in my repository ( the
auto-delete='false' does not work also when updating objects ).
 
 
 
Is somebody could help me ?
May be the Armin's patch is enough , i 'll test it .
 
 
B.R 
 
 
Thierry 
 
 
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Help M-To-N relation update => deletion of referenced objects .

[Thierry Hanot]

I've just tried with the last cvs version . I still have the problem . 
It seem's that the removalAware Collections should not delete objects if the
related collection is not in auto-delete="true" or auto-update="true" . 
Is somebody could help me with this ?

B.R 

Thierry 


-Original Message-
From: Thierry Hanot [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 01, 2004 7:52 PM
To: [EMAIL PROTECTED]
Subject: Help M-To-N relation update => deletion of referenced objects .


Hello  all 
 
I have a big pbm ...
 
I'm using a M-TO-N relation something like:


 
 

 
 
 
My problem is when i update a project after removing some reference on some
personne the personne are deleted.
 
After looking in obj internally , i see that ojb use a
RemovalAwareCollection for keeping the personnes list in the projet. After
the collection update ( in storeCollection ) the PB call the method
afterStore in the RemovalAwareCollection . This method call delete on the
removed elements ( the referenced elements not the links ... ) .
 
I tried to used a proxy ,  i still have the problem . 
 
In fact i have the problem on all collection in my repository ( the
auto-delete='false' does not work also when updating objects ).
 
 
 
Is somebody could help me ?
May be the Armin's patch is enough , i 'll test it .
 
 
B.R 
 
 
Thierry 
 
 
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Help M-To-N relation update => deletion of referenced objects .

[Thierry Hanot]

Hello  all 
 
I have a big pbm ...
 
I'm using a M-TO-N relation something like:


 
 

 
 
 
My problem is when i update a project after removing some reference on some
personne the personne are deleted.
 
After looking in obj internally , i see that ojb use a
RemovalAwareCollection for keeping the personnes list in the projet.
After the collection update ( in storeCollection ) the PB call the method
afterStore in the RemovalAwareCollection .
This method call delete on the removed elements ( the referenced elements
not the links ... ) .
 
I tried to used a proxy ,  i still have the problem . 
 
In fact i have the problem on all collection in my repository ( the
auto-delete='false' does not work also when updating objects ).
 
 
 
Is somebody could help me ?
May be the Armin's patch is enough , i 'll test it .
 
 
B.R 
 
 
Thierry 
 
 
 
 

Re: Searching in a class hierachy (ODMG)

[Brian McCallister]

Does the table OJBStudent is mapped to have the column? OJB is smart 
about only querying on tables that define attributes across extents.

How are these classes mapped and what does the schema look like?

-Brian

On Apr 1, 2004, at 10:00 AM, Keith Rogers wrote:

I have a hierachy of classes that goes like this:

user->person->student

the user has a property called userStatus, which is a reference to
another table.
What I'm trying to do is get a list of students with a particular
userStatus
When I do the query for users like this:

select ojbs from com.mp.hato.OJBUser where userStatus=1

It works fine. However, when I try

select ojbs from com.mp.hato.OJBStudent where userStatus=1

I get a message

java.sql.SQLException: Column not found,  message from server: "Unknown
column 'userStatus' in 'where clause'"
Why is this happening when I use the student class, but not the user
class? As far as I can tell, apart from this the inheritance has worked
fine - if I retreived a student object I can access all the inherited
fields, including the userStatus. So, I think its a problem with the
query rather than the inheritance setup.
Does anyone have any ideas?

The information in this e-mail is confidential and intended to be 
solely for the use of the addressee(s) and may contain copyright 
and/or legally privileged information.  If you are not the addressee 
(or responsible for delivery of the message to the addressee) please 
e-mail us at [EMAIL PROTECTED] and delete the message from 
your computer; copying, distribution, use or disclosure of its 
contents is strictly prohibited.
As Internet communications are capable of data corruption no 
responsibility is accepted for changes made to this message after it 
was sent. For this reason it may be inappropriate to rely on advice 
contained in any e-mail without obtaining written confirmation of it.
In addition, no liability or responsibility is accepted for viruses 
and it is your responsibility to scan attachments (if any).
Please note that for business purposes, outgoing and incoming emails 
from and to the company may be monitored and recorded.

Mouchel Parkman UK Ltd, Registered in England at West Hall, Parvis 
Road, West Byfleet, Surrey UK KT14 6EZ Registered No : 1686040

-
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]

Searching in a class hierachy (ODMG)

[Keith Rogers]

I have a hierachy of classes that goes like this:

user->person->student

the user has a property called userStatus, which is a reference to
another table.
What I'm trying to do is get a list of students with a particular
userStatus

When I do the query for users like this:

select ojbs from com.mp.hato.OJBUser where userStatus=1

It works fine. However, when I try

select ojbs from com.mp.hato.OJBStudent where userStatus=1

I get a message

java.sql.SQLException: Column not found,  message from server: "Unknown
column 'userStatus' in 'where clause'"

Why is this happening when I use the student class, but not the user
class? As far as I can tell, apart from this the inheritance has worked
fine - if I retreived a student object I can access all the inherited
fields, including the userStatus. So, I think its a problem with the
query rather than the inheritance setup.

Does anyone have any ideas?


The information in this e-mail is confidential and intended to be solely for the use 
of the addressee(s) and may contain copyright and/or legally privileged information.  
If you are not the addressee (or responsible for delivery of the message to the 
addressee) please e-mail us at [EMAIL PROTECTED] and delete the message from your 
computer; copying, distribution, use or disclosure of its contents is strictly 
prohibited.
As Internet communications are capable of data corruption no responsibility is 
accepted for changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice contained in any e-mail without obtaining written 
confirmation of it.
In addition, no liability or responsibility is accepted for viruses and it is your 
responsibility to scan attachments (if any).
Please note that for business purposes, outgoing and incoming emails from and to the 
company may be monitored and recorded.

Mouchel Parkman UK Ltd, Registered in England at West Hall, Parvis Road, West Byfleet, 
Surrey UK KT14 6EZ Registered No : 1686040


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Null Value generated if auto-retrieve set to false

[Guido Beutler]

Hi Armin,

works great. Thanks very much :-)

As you could see from my mail I started moving from primitives to objects.
Your performance argument for 1:n is a very strong one.
The null value problem was a side effect of my work.
best regards,

Guido

Armin Waibel wrote:

Hi Guido,

Guido Beutler wrote:

Hello,

I set the auto-retrieve attribute at repository to false for a 1:1 
relationship.
I need the reference for a query but in most cases I do not want to 
read the referenced object.

After reading a instance I tried to store the same unmodified object 
again.
I run into a SQL error during the update statement "can not write 
null into not null field".
After some debugging I realized that the missing field is the FK 
field of not materialized 1:1 reference object.

We do a refactoring of the auto-xxx settings to prevent this problem. 
In your case set auto-update="none" instead of "false". Please see
http://db.apache.org/ojb/tutorial3.html#1:1%20auto-xxx%20setting

If you want to use auto-update="object" or "true", then you have to 
load the reference first, see
http://db.apache.org/ojb/tutorial3.html#auto-retrieve%20setting

Does this solve you problem?
By the way, in rc6 is bug when set auto-delete="false", OJB interpret 
it as "true", so better use "none". It's fixed in CVS.

regards,
Armin
If I remove the reference descriptor from the mapping everything 
works fine, but my queries won't work.
For me it looks like storing an object when auto-retrieve is set to 
false fails.
I expected that ojb recognize that the auto-retrieve attribute was 
set to false and then takes
the fk attribute field for the update and not the reference which may 
be null (because not retrieved).
The fk field is of type Integer. The integer Object is filled with 
the correct value.

Any idea?

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]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[bug] rc6 1:1 relation, auto-delete="false" does delete reference

[Armin Waibel]

Hi all,

in rc6 for 1:1 relation auto-delete="false" was ignored and the 
reference was deleted too on deletion of main object. This is fixed in 
CVS. Workaround set auto-delete="none" instead.

regards,
Armin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Null Value generated if auto-retrieve set to false

[Armin Waibel]

Hi Guido,

Guido Beutler wrote:

Hello,

I set the auto-retrieve attribute at repository to false for a 1:1 
relationship.
I need the reference for a query but in most cases I do not want to read 
the referenced object.

After reading a instance I tried to store the same unmodified object again.
I run into a SQL error during the update statement "can not write null 
into not null field".
After some debugging I realized that the missing field is the FK field 
of not materialized 1:1 reference object.

We do a refactoring of the auto-xxx settings to prevent this problem. In 
your case set auto-update="none" instead of "false". Please see
http://db.apache.org/ojb/tutorial3.html#1:1%20auto-xxx%20setting

If you want to use auto-update="object" or "true", then you have to load 
the reference first, see
http://db.apache.org/ojb/tutorial3.html#auto-retrieve%20setting

Does this solve you problem?
By the way, in rc6 is bug when set auto-delete="false", OJB interpret it 
as "true", so better use "none". It's fixed in CVS.

regards,
Armin
If I remove the reference descriptor from the mapping everything works 
fine, but my queries won't work.
For me it looks like storing an object when auto-retrieve is set to 
false fails.
I expected that ojb recognize that the auto-retrieve attribute was set 
to false and then takes
the fk attribute field for the update and not the reference which may be 
null (because not retrieved).
The fk field is of type Integer. The integer Object is filled with the 
correct value.

Any idea?

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]

Null Value generated if auto-retrieve set to false

[Guido Beutler]

Hello,

I set the auto-retrieve attribute at repository to false for a 1:1 
relationship.
I need the reference for a query but in most cases I do not want to read 
the referenced object.

After reading a instance I tried to store the same unmodified object again.
I run into a SQL error during the update statement "can not write null 
into not null field".
After some debugging I realized that the missing field is the FK field 
of not materialized 1:1 reference object.

If I remove the reference descriptor from the mapping everything works 
fine, but my queries won't work.
For me it looks like storing an object when auto-retrieve is set to 
false fails.
I expected that ojb recognize that the auto-retrieve attribute was set 
to false and then takes
the fk attribute field for the update and not the reference which may be 
null (because not retrieved).
The fk field is of type Integer. The integer Object is filled with the 
correct value.

Any idea?

best regards,

Guido

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [bug] cannot reach data in chaining iterator because resource s ar e closed

[Armin Waibel]

Armin Waibel wrote:

Suppose i do not call the releaseresources method, what would happen? 
Would
it produce a memory leak?

hmm, what do you expect? ;-)
If you don't release the resources all ResultSet and Statement will not 
be closed, thus the side-effects depend on your jdbc-driver (normally 
the driver close these resources by himself).
Forget to mention, if we pool the Connection then I guess the Statement 
and ResultSet will "never" be closed and could cause memory leaks.

Armin


But if an OJBIterator implementation does some intern cleanup (free used 
objects or something similar) it may cause memory leaks.

regards,
Armin
thanx for the quick repsonse,

roger

*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this 
communication without the authority of iBanx bv. iBanx bv is neither 
liable for the proper and complete transmission of the information has 
been maintained
nor that the communication is free of viruses, interceptions or 
interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [bug] cannot reach data in chaining iterator because resource s ar e closed

[Armin Waibel]

Hi Roger,

Janssen, Roger wrote:
There is no problem when the resultset is presented as a collection. Why is
that?
Is the collection build by iterating over the resultset? 

Exactly. The Iterator holds an open ResultSet and materialize the object 
when 'next()' was called.
OJB iterate over an OJBIterator instance to populate the Collection, 
thus the Collection instance has no dependency to PB or Connection.

Suppose i do not call the releaseresources method, what would happen? Would
it produce a memory leak?
hmm, what do you expect? ;-)
If you don't release the resources all ResultSet and Statement will not 
be closed, thus the side-effects depend on your jdbc-driver (normally 
the driver close these resources by himself).
But if an OJBIterator implementation does some intern cleanup (free used 
objects or something similar) it may cause memory leaks.

regards,
Armin
thanx for the quick repsonse,

roger

*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Probleml with Mapping Inheritance Hierarchies

[Edson Carlos Ericksson Richter]

Yes, I already have done it.
There is no chance to include the class name into identity object when 
checking the PK id?

Best regards,
Edson Richter
Jakob Braeuchi wrote:

hi edson,

the Identity uses pk only. so you'd have to declare ojbConcreteClass 
part of the pk.

jakob

Edson Carlos Ericksson Richter wrote:

I did it diferencing them by the class name (I put the 
ojbConcreteClass - I know this is not really needed, but I think any 
identifier is ok).
So, there is no chance to OJB identify (by the complete class name) 
that the classes are not same for same PK id, and then use correct 
class-descriptor and instantiate correct class?

Jakob Braeuchi wrote:

hi edson,

this is imo a know fact. ojb requires to pk to be unique within a 
class hierarchy. let's assume you have a class D referencing 1:1 an 
A identified by
id =1. if this id is not unique in the class hierarchy, then ojb 
does not know if it's an A, B or C. imo there's no other way than to 
define th pk unique.

jakob

Edson Carlos Ericksson Richter wrote:

Of course, I'll try (all package test).

public class A {
 public int id;
 public String description;
}
public class B extends A {
 public double value;
}
public class C extends A {
 public Date value;
}

   
   


 
   
   


class="test.C" table="tableC">
 
  name="id"
  column="id"
   jdbc-type="INTEGER"
   primary-key="true"/>
   
   name="description"
column="description"
jdbc-type="VARCHAR"/>
   
   name="value"
   column="value"

conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlTimestampFieldConversion" 

jdbc-type="TIMESTAMP"/>

Now fill with data:

insert into tableB (id, description, value) values (1, 'testB1', 
123.45)
insert into tableB (id, description, value) values (2, 'testB2', 
234.56)
insert into tableC (id, description, value) values (1, 'testC1', 
'2004-04-01 00:00:00.000')
insert into tableC (id, description, value) values (2, 'testC2', 
'2004-04-01 00:00:00.000')

Then try to read all with query by criteria, or something, over 
test.A class. You will get a collection of 4 objects B or 4 objects 
C (depending what the databased returned first!!!).

The problem here as far as I can see is because either B and C has 
exactly same PK definition and same values for PKs. As I related, 
if I add some kind of  field to diferentiate the PK, result is right.

Best regards,

Edson Richter



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
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: [question] rc4 to rc6, fullSize method deprecated, and not fu ncti onal

[Jakob Braeuchi]

hi roger,

imo it should be factored out when Query#fullSize is removed.

jakob

Janssen, Roger wrote:

i commited a fix to QueryReferenceBroker#getCollectionByQuery to
reestablish the 

funcionality of the deprecated Query#fullSize.


Is this a temporary fix, or will it be factored out in the future? If this
is not the way to go, i will refactor some of my code to comply with the new
release/functionality as it is.
thanx anyway...

roger

*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [question] rc4 to rc6, fullSize method deprecated, and not fu ncti onal

[Janssen, Roger]

>i commited a fix to QueryReferenceBroker#getCollectionByQuery to
reestablish the 
>funcionality of the deprecated Query#fullSize.

Is this a temporary fix, or will it be factored out in the future? If this
is not the way to go, i will refactor some of my code to comply with the new
release/functionality as it is.

thanx anyway...

roger


*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [question] rc4 to rc6, fullSize method deprecated, and not fu ncti onal

[Janssen, Roger]

>hi roger,

>dou you use getCollectionByQuery or getIteratorByQuery ? the iterator
returned 
>by the latter can be casted to OjbIterator.

>jakob

We use both, in fact all, methods to retrieve data. We build a layer on top
of OJB exposing some of the OJB functionality. I already implemented a
workaround in this layer reagrding this issue, so it does not loose
functionality. However their might be some performance loss caused by the
workaround.

My question is [i just mailed it in another response to the list] what would
happen if i were not to call the releaseresources method? Would it produce a
memory leak?

And if a were to release the resources, i would have to create a new
iterator/collection containing the resultset from the ojbiterator. I believe
the only way is to just iterate over it and add every item to new
iterator/collection?

thanx,

roger


*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [bug] cannot reach data in chaining iterator because resource s ar e closed

[Janssen, Roger]

>You are right this is a problem, method 'setAutoRelease' is only defined 
>in RsIterator. I will add this method to OJBIterator interface earliest 
>in 1.1 (see comment in RsIterator#setAutoRelease), because changes in a 
>top-level interface are not welcome in a RC. But in PagingIterator and 
>ChainingIterator this method does not exist, so no cast is possible.
>Would it help you if we implement 'setAutoRelease' in these classes?

Yes, it would be consistent to implement these methods on the other
iterators as well.

>regards,
>Armin

There is no problem when the resultset is presented as a collection. Why is
that?
Is the collection build by iterating over the resultset? 

Suppose i do not call the releaseresources method, what would happen? Would
it produce a memory leak?

thanx for the quick repsonse,

roger


*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [question] rc4 to rc6, fullSize method deprecated, and not functi onal

[Jakob Braeuchi]

hi roger,

i commited a fix to QueryReferenceBroker#getCollectionByQuery to reestablish the 
funcionality of the deprecated Query#fullSize.

please check it out.

jakob

Janssen, Roger wrote:

Hi,
 
I'm trying to migrate from rc4 to rc6. I noticed that the fullSize method on
query in rc6 always returns 0. Because of this i noticed that this methode
has been deprecated. It says i should use the fullSize method on the
OJBIterator interface. I could use this, but then i have to refactor into
using ManageableCollections, and that might not be possible for me. Even if
possible, I do not want this, because it seems their is no way to get a
Collection out of a ManageableCollection, and i do need a Collection [and i
do need the availability of the fullSize method].
 
Is there somehow a way that i am able to determine the fullsize and have a
Collection as result after issuing a query??
 
thanx,
 

Roger Janssen
mailto:[EMAIL PROTECTED]
iBanx B.V http://www.ibanx.nl   
Kon. Wilhelminaplein 13 tel +31-20-5727900  
P.O. Box 69289  fax +31-20-5727901  
1060 CH Amsterdam   mobile +31-6-505 267 13 
The Netherlands 
 

*
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication 
without the authority of iBanx bv. iBanx bv is neither liable for 
the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.

If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]