objectbridge-developers — public list for developer issues

AW: [OJB-developers] enhanced report queries

[Mahler T. <tho...@it...>]

Hi Jakob,


<snip cool proposal of new ReportQuery functionality>
> 
> thomas: if you find this patch useful, please let me know, 
> and i'll check it
> in to cvs.
>

Yes these are very usefull additions! You should definitely check in your
code !

cu,

Thomas
 
> 
> 
> 

[OJB-developers] oql

[Georg S. <ge...@me...>]

Hi,

I have a question regarding OQL. Let's say I have an object A that has a
1:1 relationship with an Object B. I then want to be able to say

select allA from A where B=$1

I would then bind an instance of B which I retrieved earlier from the db
to this query. In the background SQL-Code should be generated that checks
for equivalence of the primary key fields (id). What is happening now, is
that the object I pass in as $1 is directly bound to the prepared
statement which doesn't work.
Is this valid OQL, or am I assuming something wrong.

regards

Georg

[OJB-developers] enhanced report queries

[Jakob B. <jbr...@fr...>]

hi,

the attached zip contains some enhancements for reports (queries returning
rows not 'real' objects):
- define the columns to be selected (column names are properly resolved
using the field description if available)
- allow joins in selected columns

System.out.println("\nreport (id,name,vorname,konti.saldo) with name like
'%er'");
crit = new Criteria();
crit.addEqualTo("name", "%er");
query = new QueryByCriteria(Person.class, crit);
query.setColumns(new String[]{"id","name","vorname","konti.saldo"});    //
define the columns
broker.getReportQueryIteratorByQuery(query);

this also allows some aggregate queries, but column names are NOT resolved
(no field decription for 'sum(test)' ):

System.out.println("\nreport (sum(test) with name like '%er'");
crit = new Criteria();
crit.addEqualTo("name", "%er"); // uses Like
query = new QueryByCriteria(Person.class, crit);
query.setColumns(new String[]{"sum(test)"});        // column name is NOT
resolved here
broker.getReportQueryIteratorByQuery(query);


jakob

thomas: if you find this patch useful, please let me know, and i'll check it
in to cvs.

[Fwd: Re: [OJB-developers] Cache of Collections]

[Thomas M. <tho...@ho...>]

-------- Original Message --------
Subject: Re: [OJB-developers] Cache of Collections
Date: Sat, 09 Mar 2002 11:56:26 +0100
From: Thomas Mahler <tho...@ho...>
To: John Wang <hw...@re...>
References: 
<Pin...@sc...> 
<3C8...@ho...> <00a001c1c6de$6b3ec640$5901a8c0@JWANG>

Hi John,

John Wang wrote:

 > I am wondering about how JOB handles the cache of collections?
 > Say, A has many B,
 > first I get A, it contains a collection of B, and the object A is put 
into
 > the cache
 > then Another user has added an object B, this time the object A's B
 > collection should contain the new B,
 > Can JOB handles that? Or at least it should invalidate the object A 
or A's B
 > collection.
 >


Yes such situation are handled correctly. The cache maintains uniqueness
of objects. That is if a user looks up an identity I he is returned
Object A. If another user looks up the same identity he is returned the
same Object A.


 > BTW, does client/server model work for the current version? 
(0.7.343). And
 > it support distrubuted cache of objects?
 >


Yes !

Thomas


 > Thanks a lot,
 > John W

[Fwd: Re: [OJB-developers] About connection pool and preparedstatement cache]

[Thomas M. <tho...@ho...>]

-------- Original Message --------
Subject: Re: [OJB-developers] About connection pool and 
preparedstatement cache
Date: Sat, 09 Mar 2002 12:04:41 +0100
From: Thomas Mahler <tho...@ho...>
To: John Wang <hw...@re...>
References: 
<Pin...@sc...> 
<000b01c1c6f4$8f354f40$5901a8c0@JWANG>

Hi John,

John Wang wrote:

 > I noticed that for a class, it  can only use the same connection, 
even for
 > different users. So when 2 users are accessing the same class 
objects, they
 > will share the same connection, and may cause some problem, right?
 >


Why should this be problematic? a PersistenceBroker handles only one
JDBC transaction at a time. If two threads (or users) are working with
the the same broker only one of them can perform transactional
operations at a time.

If two threads (or users) need to work in parallel they have to obtain
individual PersistenceBrokers. As each PersistenceBroker holds its own
Connections there is again no problem here.

What kind of problems are you thinking of?


 > In ConnectionManager.getConnectionForClassDescriptor, it will get from
 > hashmap, so it will return the same for a classdescriptor.
 >


Yes, per broker it's possible to have a dedicated Connection for each
persistent Class. but in general all classes share a default connection.


 > The preparedstatement is also cached in the StatementsforClass, which is
 > good. I am just wondering whether it can live outside of a connection.
 >



PreparedStatements depend on a active Connection. Thus before using a
cached PreparedStatement OJB always checks if the Connection is still alive.

HTH,

Thomas


 > Thanks a lot,
 > John W
 >
 >
 > ----- Original Message -----
 > From: "Georg Schneider" <ge...@me...>
 > To: <obj...@li...>
 > Sent: Friday, March 08, 2002 1:33 AM
 > Subject: [OJB-developers] dynamic proxies
 >
 >
 >
 >>Hi,
 >>
 >>I just implemented a few lines to enable dynamic proxies to also 
implement
 >>interfaces which are implemented by classes further up the inheritance
 >>hierarchy. I just added the following lines in RepositoryXmlHandler 
in the
 >>method getDynamicProxyClass:
 >>
 >>            Class[] interfaces = clazz.getInterfaces();
 >>    //added from here on
 >>    Class superClass = clazz;
 >>
 >>    while((superClass = superClass.getSuperclass()) != null) {
 >>
 >>Class[] superInterfaces = superClass.getInterfaces();
 >>
 >>Class[] combInterfaces =
 >>    new Class[interfaces.length +
 >>      superInterfaces.length];
 >>System.arraycopy(interfaces,0,combInterfaces,0,
 >>interfaces.length);
 >>System.arraycopy(superInterfaces,0,combInterfaces,
 >>interfaces.length,
 >>superInterfaces.length);
 >>interfaces = combInterfaces;
 >>    }
 >>    //end added
 >>
 >>            Class proxyClass = Proxy.getProxyClass(
 >>                    clazz.getClassLoader(), interfaces);
 >>
 >>
 >>Regards
 >>
 >>Georg
 >>
 >>
 >>_______________________________________________
 >>Objectbridge-developers mailing list
 >>Obj...@li...
 >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >>
 >
 >
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
 >
 >
 >
 >

[OJB-developers] About connection pool and preparedstatement cache

[John W. <hw...@re...>]

I noticed that for a class, it  can only use the same connection, even for
different users. So when 2 users are accessing the same class objects, they
will share the same connection, and may cause some problem, right?

In ConnectionManager.getConnectionForClassDescriptor, it will get from
hashmap, so it will return the same for a classdescriptor.

The preparedstatement is also cached in the StatementsforClass, which is
good. I am just wondering whether it can live outside of a connection.

Thanks a lot,
John W


----- Original Message -----
From: "Georg Schneider" <ge...@me...>
To: <obj...@li...>
Sent: Friday, March 08, 2002 1:33 AM
Subject: [OJB-developers] dynamic proxies


> Hi,
>
> I just implemented a few lines to enable dynamic proxies to also implement
> interfaces which are implemented by classes further up the inheritance
> hierarchy. I just added the following lines in RepositoryXmlHandler in the
> method getDynamicProxyClass:
>
>             Class[] interfaces = clazz.getInterfaces();
>     //added from here on
>     Class superClass = clazz;
>
>     while((superClass = superClass.getSuperclass()) != null) {
>
> Class[] superInterfaces = superClass.getInterfaces();
>
> Class[] combInterfaces =
>     new Class[interfaces.length +
>       superInterfaces.length];
> System.arraycopy(interfaces,0,combInterfaces,0,
> interfaces.length);
> System.arraycopy(superInterfaces,0,combInterfaces,
> interfaces.length,
> superInterfaces.length);
> interfaces = combInterfaces;
>     }
>     //end added
>
>             Class proxyClass = Proxy.getProxyClass(
>                     clazz.getClassLoader(), interfaces);
>
>
> Regards
>
> Georg
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] Cache of Collections

[John W. <hw...@re...>]

I am wondering about how JOB handles the cache of collections?
Say, A has many B,
first I get A, it contains a collection of B, and the object A is put into
the cache
then Another user has added an object B, this time the object A's B
collection should contain the new B,
Can JOB handles that? Or at least it should invalidate the object A or A's B
collection.

BTW, does client/server model work for the current version? (0.7.343). And
it support distrubuted cache of objects?

Thanks a lot,
John W
----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Georg Schneider" <ge...@me...>
Cc: <obj...@li...>
Sent: Friday, March 08, 2002 10:59 AM
Subject: Re: [OJB-developers] OQL bug


> Hi Georg,
>
> Oops this is a very tough problem. This will be quite difficult to fix.
> The best thing would be to support usage of methods in OQL query like
> "select x from X where getSequence().getSomeField() = $1"
>
> This way we could avoid all the trouble caused by looking for persistent
> attributes in interface classdescriptors.
>
> I'll put this on the todo list. But it will take some time to fix! (Any
> volunteers?)
>
> thanks,
>
> Thomas
>
> Georg Schneider wrote:
>
> > Hi,
> >
> > when something similar as the following OQL-Query
> >
> > select allX from X where sequence.somefield = $1 ....
> >
> > where the sequence field is actually an interface I get a
> > NullPointerException:
> >
> > java.lang.NullPointerException
> >         at
> >
ojb.broker.metadata.ClassDescriptor.getPkFields(ClassDescriptor.java:869)
> >         at
> >
ojb.broker.accesslayer.SqlGenerator$JoinInfo.asSqlClause(SqlGenerator.java:6
6)
> >         at
> > ojb.broker.accesslayer.SqlGenerator.getJoinClause(SqlGenerator.java:914)
> >         at
> >
ojb.broker.accesslayer.SqlGenerator.getPreparedSelectStatement(SqlGenerator.
java:685)
> >         at
> > ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:186)
> >         at ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:179)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBr
okerImpl.java:1181)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBr
okerImpl.java:901)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBr
okerImpl.java:986)
> >         at
> >
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBr
okerImpl.java:958)
> >         at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:229)
> >
> >
> > I looked a little bit around and the problem seems to be in the inner
> > class JoinInfo in SqlGenerator which tries to do the following
> >
> >             refCld =
> > aCld.getRepository().getDescriptorFor(anOrd.getItemClass());
> >
> >
> > anOrd.getItemClass() of course is an interface which as a Descriptor
> > doesn't have any fields. I suppose the interface would have to be
> > substituted somehow by the actual classes implementing that interface
and
> > maybe this would mean having to do various actual SQL-Queries each with
a
> > concrete class and then somehow merging the result, or doing an
> > (outer) join over all the concrete class tables involved and then
somehow
> > postprocessing the result again.
> >
> > regards
> >
> > Georg
> >
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] OQL bug

[Thomas M. <tho...@ho...>]

Hi Georg,

Oops this is a very tough problem. This will be quite difficult to fix.
The best thing would be to support usage of methods in OQL query like
"select x from X where getSequence().getSomeField() = $1"

This way we could avoid all the trouble caused by looking for persistent 
attributes in interface classdescriptors.

I'll put this on the todo list. But it will take some time to fix! (Any 
volunteers?)

thanks,

Thomas

Georg Schneider wrote:

> Hi,
> 
> when something similar as the following OQL-Query
> 
> select allX from X where sequence.somefield = $1 ....
> 
> where the sequence field is actually an interface I get a
> NullPointerException:
> 
> java.lang.NullPointerException
>         at
> ojb.broker.metadata.ClassDescriptor.getPkFields(ClassDescriptor.java:869)
>         at
> ojb.broker.accesslayer.SqlGenerator$JoinInfo.asSqlClause(SqlGenerator.java:66)
>         at
> ojb.broker.accesslayer.SqlGenerator.getJoinClause(SqlGenerator.java:914)
>         at
> ojb.broker.accesslayer.SqlGenerator.getPreparedSelectStatement(SqlGenerator.java:685)
>         at
> ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:186)
>         at ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:179)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBrokerImpl.java:1181)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:901)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:986)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:958)
>         at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:229)
> 
> 
> I looked a little bit around and the problem seems to be in the inner
> class JoinInfo in SqlGenerator which tries to do the following
> 
>             refCld =
> aCld.getRepository().getDescriptorFor(anOrd.getItemClass());
> 
> 
> anOrd.getItemClass() of course is an interface which as a Descriptor
> doesn't have any fields. I suppose the interface would have to be
> substituted somehow by the actual classes implementing that interface and
> maybe this would mean having to do various actual SQL-Queries each with a
> concrete class and then somehow merging the result, or doing an
> (outer) join over all the concrete class tables involved and then somehow
> postprocessing the result again.
> 
> regards
> 
> Georg
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] OQL bug

[Georg S. <ge...@me...>]

Hi,

I thought a little bit about my last posting and of course the thing I did
was quite stupid since interfaces can not have fields. The query would
have to be
select allX from X where sequence.getSomeField() = $1

I do not know if this is correct OQL and even then it would be a
performance problem because the query engine would have to load each
object to invoke the method.

Anyway let me explain why I even got to that problem.
I actually wanted to do something like this:
select allX from X where sequence= $1

sequence is a reference field that holds an interface of type Sequence.

Please correct me if this is not possible in OQL, but I thought that I
could pass in an object when binding. My problem was that I passed in an
object which is loaded with dynamic proxy turned on. The query engine than
threw an error that it did not know a class $Proxy2. Somehow the engine
should substitute the actual interface or object for the proxy.

regards

Georg

On Fri, 8 Mar 2002, Georg Schneider wrote:

> Hi,
>
> when something similar as the following OQL-Query
>
> select allX from X where sequence.somefield = $1 ....
>
> where the sequence field is actually an interface I get a
> NullPointerException:
>
> java.lang.NullPointerException
>         at
> ojb.broker.metadata.ClassDescriptor.getPkFields(ClassDescriptor.java:869)
>         at
> ojb.broker.accesslayer.SqlGenerator$JoinInfo.asSqlClause(SqlGenerator.java:66)
>         at
> ojb.broker.accesslayer.SqlGenerator.getJoinClause(SqlGenerator.java:914)
>         at
> ojb.broker.accesslayer.SqlGenerator.getPreparedSelectStatement(SqlGenerator.java:685)
>         at
> ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:186)
>         at ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:179)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBrokerImpl.java:1181)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:901)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:986)
>         at
> ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:958)
>         at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:229)
>
>
> I looked a little bit around and the problem seems to be in the inner
> class JoinInfo in SqlGenerator which tries to do the following
>
>             refCld =
> aCld.getRepository().getDescriptorFor(anOrd.getItemClass());
>
>
> anOrd.getItemClass() of course is an interface which as a Descriptor
> doesn't have any fields. I suppose the interface would have to be
> substituted somehow by the actual classes implementing that interface and
> maybe this would mean having to do various actual SQL-Queries each with a
> concrete class and then somehow merging the result, or doing an
> (outer) join over all the concrete class tables involved and then somehow
> postprocessing the result again.
>
> regards
>
> Georg
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

[OJB-developers] OQL bug

[Georg S. <ge...@me...>]

Hi,

when something similar as the following OQL-Query

select allX from X where sequence.somefield = $1 ....

where the sequence field is actually an interface I get a
NullPointerException:

java.lang.NullPointerException
        at
ojb.broker.metadata.ClassDescriptor.getPkFields(ClassDescriptor.java:869)
        at
ojb.broker.accesslayer.SqlGenerator$JoinInfo.asSqlClause(SqlGenerator.java:66)
        at
ojb.broker.accesslayer.SqlGenerator.getJoinClause(SqlGenerator.java:914)
        at
ojb.broker.accesslayer.SqlGenerator.getPreparedSelectStatement(SqlGenerator.java:685)
        at
ojb.broker.accesslayer.JdbcAccess.executeQuery(JdbcAccess.java:186)
        at ojb.broker.accesslayer.RsIterator.<init>(RsIterator.java:179)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.getIteratorFromQuery(PersistenceBrokerImpl.java:1181)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:901)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:986)
        at
ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:958)
        at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:229)


I looked a little bit around and the problem seems to be in the inner
class JoinInfo in SqlGenerator which tries to do the following

            refCld =
aCld.getRepository().getDescriptorFor(anOrd.getItemClass());


anOrd.getItemClass() of course is an interface which as a Descriptor
doesn't have any fields. I suppose the interface would have to be
substituted somehow by the actual classes implementing that interface and
maybe this would mean having to do various actual SQL-Queries each with a
concrete class and then somehow merging the result, or doing an
(outer) join over all the concrete class tables involved and then somehow
postprocessing the result again.

regards

Georg

RE: [OJB-developers] CVS

[<Joa...@tp...>]

> take a deep breath and relax.

Sorry, if my mail sounded as a flame or like I was angry or anything. It
was not intended. I just wanted to know wether those were known issues.
None of these issues had any _major_ impact on my working with ojb, but I
still watch ojb with beginners eyes and every thing that disturbs me from
just getting it to run is disturbing (and potentially stopping someone else
from takeing a closer look at ojb, which should be avoided, I think).

[broken newlines]
> No, this is not the fault of CVS, but of the ScriptTool that is used
> for preprocessing the java files. This is already a known issue.

i see ...

>> 2.) other files are marked as binary (sticky -kb tag), 'though they
>> should be text (-kkv) (i.e. src/test/ojb/repository_*.xml)
>
> True, but that can be fixed easily (cvs admin -kkv *.xml).

i know, i just wanted to mention it, as someone should really fix it (and I
don't have cvs write access).

>> 3.) Some classes (namely those in ojb.tools.mapping.reversedb)
>> depend on gnu-regexp, which is not in the lib-directory
>
> This is recently contributed code that Thomas added to CVS a few days
> ago. He might have missed the gnu-regexp package.

I understand, but I think such things can easily be avoided. If you require
each used library to be put into /lib then every decent IDE (or CVS client)
will show you that you have libraries in the directory that are not under
CVS control.

>> 4.) i seriously doubt that ojb-1-0/build should be under cvs
>> controll
>
> All the things you mentioned are not the fault of CVS or because of
> several people working concurrently, everything you described would
> have happened even if the project was not under CVS control. Human
> being make errors. But it is nothing that cannot be fixed.

I know that each of these things can be fixed and that none of it is an
inherent problem with CVS (although such problems do exist).

>> (now I understand why you closed down cvs, Thomas!)
>
> And I hope it remains under CVS, it makes it a lot easier to
> contribute code.

I do hope so as well, but for it to be usefull such issues have to be
sorted out and avoided in the future (probably by the "rules of conduct"
that Thomas mentioned in one of his previous mails).

I hope I don't give a bad impression. I didn't mean to just run into this
list and flame away. I wanted to raise some issues, as I know from personal
experience that some of these issues usually aren't detected when you just
work on the same working copy and that they only disrupt the workflow for
newly checked out sources and thus get less attention.

> best regards, Florian

regards
Joachim Sauer

RE: [OJB-developers] CVS

[Florian B. <bf...@fl...>]

Hi Joachim,

take a deep breath and relax.

> 1.) Some files seem to have broken new-lines (they have _both_
> unix-style &
> windows-style after each line, for example src/test/setup/db-setup.sql).
> Most editors ignore this, unfortunately IDEA (which is my IDE of choice)
> does not and puts a blank line between ech "real" line. They still work,
> but it is quite disturbing. (I've also seen this problem on our internal
> development CVS and I think it is caused by Eclipses' broken CVS
> implementation, let's hope the new CVS-Tool in Eclipse does a better job).

No, this is not the fault of CVS, but of the ScriptTool that is used for
preprocessing the java files. This is already a known issue.

> 2.) other files are marked as binary (sticky -kb tag), 'though they should
> be text (-kkv) (i.e. src/test/ojb/repository_*.xml)

True, but that can be fixed easily (cvs admin -kkv *.xml).

> 3.) Some classes (namely those in ojb.tools.mapping.reversedb) depend on
> gnu-regexp, which is not in the lib-directory

This is recently contributed code that Thomas added to CVS a few days ago.
He might have missed the gnu-regexp package.

> 4.) i seriously doubt that ojb-1-0/build should be under cvs controll

All the things you mentioned are not the fault of CVS or because of several
people working concurrently, everything you described would have happened
even if the project was not under CVS control. Human being make errors. But
it is nothing that cannot be fixed.

>
> (now I understand why you closed down cvs, Thomas!)
>

And I hope it remains under CVS, it makes it a lot easier to contribute
code.


best regards,
Florian

[OJB-developers] CVS

[<Joa...@tp...>]

Hy,

the CVS repository seems somewhat ... let's say chao^H^H^Hreative ... I had
several problems when checking out from CVS:

1.) Some files seem to have broken new-lines (they have _both_ unix-style &
windows-style after each line, for example src/test/setup/db-setup.sql).
Most editors ignore this, unfortunately IDEA (which is my IDE of choice)
does not and puts a blank line between ech "real" line. They still work,
but it is quite disturbing. (I've also seen this problem on our internal
development CVS and I think it is caused by Eclipses' broken CVS
implementation, let's hope the new CVS-Tool in Eclipse does a better job).
2.) other files are marked as binary (sticky -kb tag), 'though they should
be text (-kkv) (i.e. src/test/ojb/repository_*.xml)
3.) Some classes (namely those in ojb.tools.mapping.reversedb) depend on
gnu-regexp, which is not in the lib-directory
4.) i seriously doubt that ojb-1-0/build should be under cvs controll

(now I understand why you closed down cvs, Thomas!)

btw, shouldn't the tests-target in build.xml depend on main? Normally this
isn't a problem, as you use it primarily after some coding & compiling, but
I just tripped over it ...

regards
Joachim Sauer

[OJB-developers] MS SQL Server

[<Joa...@tp...>]

Hy,

we've had major problems with running the OJB tests (and the junit target)
on MS SQL Server using the MS Beta JDBC Driver. Although it was almost
definitely a JDBC-Driver issue I think you might want to hear about it:

The Problem was that running the tests target resulted in lots of timeouts
and no connections whatsoever. After some working around we found out that
the MS SQL Server JDBC Driver had a major problem with almost all kind of
Timeouts (it just sits there for the time specified and then stops, never
completing the request). So after we commented out the stmt.setQueryTimeout
() at line 610 in ScriptTool.java it worked quite fine. Is there any
special need for this statement?

btw, I'm afraid I wont find time to write the documentation that I wanted
to write, but as we now decided to use OJB (instead of JDO) at least until
the JDO implementations grow stable (but until then I hope that the JDO-API
for OJB will stand) we will have some time to contribute back to this
project.

regards
Joachim Sauer

AW: [OJB-developers] dynamic proxies

[Mahler T. <tho...@it...>]

Hi Georg,

Thanks for this patch!

Thomas

[OJB-developers] dynamic proxies

[Georg S. <ge...@me...>]

Hi,

I just implemented a few lines to enable dynamic proxies to also implement
interfaces which are implemented by classes further up the inheritance
hierarchy. I just added the following lines in RepositoryXmlHandler in the
method getDynamicProxyClass:

            Class[] interfaces = clazz.getInterfaces();
	    //added from here on
	    Class superClass = clazz;

	    while((superClass = superClass.getSuperclass()) != null) {

		Class[] superInterfaces = superClass.getInterfaces();

		Class[] combInterfaces =
		    new Class[interfaces.length +
			      superInterfaces.length];
		System.arraycopy(interfaces,0,combInterfaces,0,
				 interfaces.length);
		System.arraycopy(superInterfaces,0,combInterfaces,
				 interfaces.length,
				 superInterfaces.length);
		interfaces = combInterfaces;
	    }
	    //end added

            Class proxyClass = Proxy.getProxyClass(
                    clazz.getClassLoader(), interfaces);


Regards

Georg

[OJB-developers] bug when deleting with proxys

[Georg S. <ge...@me...>]

Hi,

I just encountered the following situation:

I want to delete an object which I retrieved via an OQL-query
The object itself is loaded dynamically.
If I then try to execute the following

db.deletePersistent(obj);

I get the following error:

org.odmg.ClassNotPersistenceCapableException: $Proxy2 not found in OJB
Repository
        at ojb.odmg.ObjectEnvelope.manage(ObjectEnvelope.java:91)
        at ojb.odmg.ObjectEnvelope.<init>(ObjectEnvelope.java:73)
        at ojb.odmg.ObjectEnvelopeTable.get(ObjectEnvelopeTable.java:156)
        at ojb.odmg.TransactionImpl.markDelete(TransactionImpl.java:423)
        at ojb.odmg.DatabaseImpl.deletePersistent(DatabaseImpl.java:253)
        at
imp.test.PersistenceTest.testPersistSimpleSequence(PersistenceTest.java:329)
        at imp.test.PersistenceTest.main(PersistenceTest.java:112)


if I add a single line before the deletePersistent where I access some
field in the object (which means that the actual object is materialized
from the database) the deletion executes without an error.

I looked at the ObjectEnvelopeTable class and obviously in the case that
the object has not been materialized prior to deletion a new
ObjectEnvelope is instantiated with the $Proxy2 class instead of the
actual class. Since I haven't dug too much into ojb yet, I don't know how
this should be done.

Another thing, I wanted to mention is the fact that when one uses dynamic
proxies, the class has to directly implement an interface. In my case for
example some classes extend a baseclass which in turn implements an
interface.

e.g. 	BaseSequence implements Sequence
	SimpleSequence extends BaseSequence

Unfortunately this leads to a ClassCastException in the
following line after an OQL-Query:

seq = (Sequence) seqs.get(0);

The problem is that in RepositoryXMLHandler in

    private Class getDynamicProxyClass(ClassDescriptor cld) {
...
            Class[] interfaces = clazz.getInterfaces();

will only return the interfaces directly implemented by clazz and not the
ones it 'inherits'. I suppose that one would have to walk through the tree
of superclasses (and possibly also the interfaces itself, if they extend
each other) to get a correct array of implemented interfaces.

By the way, it is a pleasure to read through your clear code.

regards

Georg

AW: [OJB-developers] bug in PersistenceBrokerImpl?

[Mahler T. <tho...@it...>]

Hi Georg,

<snip>
thanks for your patch, I will have a look at this issue. should be fixed in
the next release.
> 
> 
> I have another problem, which is giving me a headache. I am 
> developing on
> a UNIX system and whenever I execute build.sh the preprocessor somehow
> converts the files to contain CRLFs again. How can I turn this off?
> 

Hmm, The preprocessor is only started for certain targets. If you just use
build.sh main, junit etc. there is no preprocessing.

I'm doing all development under Linux and never had any such problems ????

Thomas

> 
> Regards
> 
> Georg
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

AW: [OJB-developers] [long] OJB+JBoss Performance and Problems

[Mahler T. <tho...@it...>]

Hi Armin,

Thanks for you interesting report!

> Hi all,
> 
<snip>
> ##################### Rollback Test ########################
> In the rollback testcase we send a list of objects to store 
> to the server.
> After
> storing the objects a hard coded exception is fired before 
> leaving method.
> We encountered a problem:
> Every call to a session bean method starts a container 
> managed transaction
> (using declarative transaction with transaction attribute required).

You are right there is currently no JTA integration !

> In our testmethod we want to simulate first storing data 
> objects and calling
> futher (e.g. sending an email) functionality.
> If something goes wrong after successfully storing the data, we want
> rollback the
> complete transaction. And this did not work out of the box, 
> cause the PB
> commits
> the database transaction (no rollback possible).
> 
>   public void performException(List offerings)
>  {
>       store(offerings);
>       throw new UnexpectedError("Performed test exception");
>  }
> 
> We use our own implementation of PersistenceBroker, which implements
> javax.transaction.Synchronization. This allows us to defer 
> the committing of
> the database
> transaction, after successfully committing the container transaction.
> The session bean registers each instance of PB with the 
> current transaction
> (see below)
> 
> Has anybody a different (better :-)) solution for this problem?
> 

I'm quite intereted in your implementation! Would you share your code? This
can be interesting for many users.

We definitely want to have JTA and JCA integration for OJB. Thus we
interested in all contributions in this direction.

Thanks,

Thomas

<snip>
> 

[OJB-developers] [long] OJB+JBoss Performance and Problems

[hafman <ha...@we...>]

Hi all,

we would like to use OJB as persistence layer and to generate views for
clients, managed by session beans in JBoss.

We do some tests to compare performance of OJB with other persistence
layers against HSQL.

We also testing a multithreaded testcase and a rollback testcase. When
running the rollback testcade
we encountered a couple of problems, see below.
OJB version 0.7344 (CVS)

################### Performance Insert/Delete ##################
1. SessionBean facade using OJB as persistence layer (3-tier) with
declarative transaction. hsql in server mode in same vm as jboss.

2. SessionBean facade using local EntityBeans as persistence layer (3-tier)
with declarative transaction. hsql in server mode in same vm as jboss.

3. Using Torque (http://jakarta.apache.org/turbine/torque/index.html), part
of the Turbine project
as persistence layer (2-tier). Turbine run in standalone modus, hsql in
server mode in DIFFERENT vm as jboss.

The test client store and remove 1000 value objects:
a. One remote call per object to store
b. List of all objects send to server to store (one remote connection to
store)
c. One remote call per object to delete
d. List of all objects send to server to remove (one remote connection to
´remove)

                            store            delete
Scenario  (ms)|   a.   |   b.   |   c.   |   d.   |
-----------------------------------------
1.SB+OJB     | 3585|  763 | 3112|   466|
2.SB+loc. EB | 4848| 2516| 3421| 1710|
3.turbine         |   --  |(1081)|   --   |(956)|

OJB does an excellent job! Performance compared
with local entiy beans as persistence layer is better by far:
~27% faster to store one object per remote call
~60% faster to store 1000 objects per remote call
Even more remarkable OJB is a bit faster then the persistence layer Torque.
(Note: Using Torque run in different vm)
Excellent performance!!
#########################################################


##################### Multithreaded Test ####################
In the multithreaded testcase running 10 clients and every client do 100
store
and delete operations.
One store/delete operation per remote call
1.SB+OJB               7503
2.SB+loc. EB           9281
Using OJB as persistence layer runs ~ 20% faster
########################################################


##################### Rollback Test ########################
In the rollback testcase we send a list of objects to store to the server.
After
storing the objects a hard coded exception is fired before leaving method.
We encountered a problem:
Every call to a session bean method starts a container managed transaction
(using declarative transaction with transaction attribute required).
In our testmethod we want to simulate first storing data objects and calling
futher (e.g. sending an email) functionality.
If something goes wrong after successfully storing the data, we want
rollback the
complete transaction. And this did not work out of the box, cause the PB
commits
the database transaction (no rollback possible).

  public void performException(List offerings)
 {
      store(offerings);
      throw new UnexpectedError("Performed test exception");
 }

We use our own implementation of PersistenceBroker, which implements
javax.transaction.Synchronization. This allows us to defer the committing of
the database
transaction, after successfully committing the container transaction.
The session bean registers each instance of PB with the current transaction
(see below)

Has anybody a different (better :-)) solution for this problem?




public class OJBSessionBean extends CALSessionBean
{
       protected TransactionManager tm;
       .....

       /**
       * Here we lookup for ojbRepository file and the TransactionManager
        */
       public void ejbCreate()
       {
               super.ejbCreate();
               .....
               tm = (TransactionManager)
Creator.lookup("java:/TransactionManager");
       }

        /**
        * Use this method to get a new PersistenceBroker instance.
         */
       public PersistenceBroker getBroker()
      {
           try
           {
                   PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(ojbRepository);
                   /*
                   associate PB with transaction of the container and begin
transaction
                   on the connection hold by PB
                   or, if we had no transaction, only return the broker
                   */
                   if (registerSynchronization(broker))
                  {
                         if (log.isDebugEnabled()) log.debug("Automatic call
PB.beginTransaction()");
                         broker.beginTransaction();
                  }
                  return broker;
            }
            catch (Exception e{throw new UnexpectedError(e);}
        }

         /**
         * Returns true, if the current thread is associated with a
transaction.
          */
         private boolean registerSynchronization(PersistenceBroker broker)
         {
               boolean hasActiveTransaction = false;
               try
              {
                     Transaction ta = tm.getTransaction();
                      if (ta != null)
                      {

ta.registerSynchronization((CALPersistenceBroker)broker);
                           hasActiveTransaction = true;
                       }
               }
               catch (Exception e){log.error("Register PersistenceBroker
failed", e);
               return hasActiveTransaction;
         }
}
########################################################


Thanks in advance
Armin

[OJB-developers] bug in PersistenceBrokerImpl?

[Georg S. <ge...@me...>]

Hi,

When executing an OQLQuery that searches for an interface instead of a
concrete class (e.g. "select seqs from Sequence where ..." , where
Sequence is an interface) and there is no matching result in the database
a  null-value is returned by broker.getCollectionByQuery... in
OQLQueryImpl.java, this results in a NullPointerException a few lines
later when trying to get the Iterator (result.ojbIterator()).


            ManageableCollection result = (ManageableCollection)
                    broker.getCollectionByQuery(this.getCollectionClass(),
query);
            broker.commitTransaction();

            // read-lock all resulting objects to the current transaction
            Iterator iter = result.ojbIterator();


The actual fault seems to lie in PersistenceBrokerImpl in

    public ManageableCollection getCollectionByQuery(Class
collectionClass, Query query, boolean lazy)
        throws PersistenceBrokerException
    {

where

ManageableCollection result = null;

is set at the beginning of the method, but if there is no match in the
database and the query was for an interface, execution falls through until
the last statement

return result;

which simply returns null


I added the following lines just before the return statement and
everything works fine, but since I haven't familiarised myself too much
with the code, I don't know if this would have other effects somewhere
else.

	if (result == null)
	    {
		try
                    {
                        result = (ManageableCollection)
collectionClass.newInstance();
                    }
		catch (Throwable t)
                    {
                        throw new PersistenceBrokerException(t);
                    }
	    }


I have another problem, which is giving me a headache. I am developing on
a UNIX system and whenever I execute build.sh the preprocessor somehow
converts the files to contain CRLFs again. How can I turn this off?


Regards

Georg

RE: [OJB-developers] Bug in ODMG transaction

[Bischof, R. <rai...@ed...>]

Thomas, 

thanks for clarification. I had seen these notes but somehow I thought that
this only affects the ODMG collections not ODMG in general.

cu
Rainer

-----Original Message-----
From: Thomas Mahler [mailto:tho...@ho...]
Sent: Dienstag, 5. Marz 2002 18:22
To: Bischof, Rainer
Cc: OJB
Subject: Re: [OJB-developers] Bug in ODMG transaction


Hi again Rainer,

Bischof, Rainer wrote:

> Hi,
>  
> I just moved to the current release which should fix some bugs with
foreign
> keys and the ODMG interface. I discovered two more:
>  
> 1. Object A references Object B of a different class in a 1-1
relationship.
> A's PK consists only of the reference to B (i.e. B's PK, which is
> auto-incremented). Both objects are newly created and properly locked with
> the ODMG transaction. B's PK is incremented at that time but A's FK to B
is
> not updated at that time (this is done only in broker.store). Therefore
A's
> FK to B is 0 which does not work. OJB places a lock on an object whose PK
is
> not yet defined.
> Solution: FKs must be assigned before the lock is performed. I modified
the
> TransactionImpl to do this by copying the methods of the broker that
perform
> that to the TransactionImpl. That's just a quick and ugly hack but works. 
>  


Thanks for your patch. I will have a look at this issue


>  
> 2. Object A holds a collection of Bs. Auto-Update is set to true in the
> repository. I create A and lock it, than I create some Bs, lock them and
add
> them to A's collection. On commit the ObjectEnvelopeTable first stores A
> which also stores it's collections. Afterwards the ObjectEnvelopeTable
goes
> through the ObjectEnvelopes of all Bs. All of these Bs have a
StateNewDirty
> which always creates INSERT statements. But the Bs have already been
stored
> as part of A's collection.
>  
> I currently do not have the time to provide a proper fix for this ( I just
> switched of AutoUpdate and it worked for me).
>  


Auto-Update and -Delete *must not* be set to true if working with the 
ODMG Implementation. There is no fix for this, it just does not work!
This is stated in http://objectbridge.sf.net/tutorial3.html#cascading.

cu,

Thomas


> Regards
> Rainer
>  
>  
> 

[OJB-developers] JDBCAccess performance optimization

[Jakob B. <jbr...@ho...>]

hi,

the performance optimization in JDBCAccess crashes or at least slows down
QueryBySQL:

sql = "select * from tabPerson where name like '%er'";
query = new QueryBySQL(Person.class, sql);

in the above sample the sequence of the columns may not match the sequence
of the fields in the ClassDescriptor, that's why i
got the column id from the resultset  using findColumn().

static Object getObjectFromColumn(ResultSet rs, FieldDescriptor fld) throws
SQLException
{
    int jdbcType = fld.getColumnJdbcType();
    int columnId = fld.getColNo(); //rs.findColumn(fld.getColumnName());
//use columnId from rs BRJ
    return getObjectFromColumn(rs, jdbcType, columnId);
}

i do not know how much this lookup affects performance.
but for QueryBySQL it has a negative effect because the SqlBaseIterator may
get an
exception in the method getObjectFromResultSet() and therefore try to
retrieve the object via getObjectByIdentity().

jakob

Re: [OJB-developers] Bug in ODMG transaction

[Thomas M. <tho...@ho...>]

Hi again Rainer,

Bischof, Rainer wrote:

> Hi,
>  
> I just moved to the current release which should fix some bugs with foreign
> keys and the ODMG interface. I discovered two more:
>  
> 1. Object A references Object B of a different class in a 1-1 relationship.
> A's PK consists only of the reference to B (i.e. B's PK, which is
> auto-incremented). Both objects are newly created and properly locked with
> the ODMG transaction. B's PK is incremented at that time but A's FK to B is
> not updated at that time (this is done only in broker.store). Therefore A's
> FK to B is 0 which does not work. OJB places a lock on an object whose PK is
> not yet defined.
> Solution: FKs must be assigned before the lock is performed. I modified the
> TransactionImpl to do this by copying the methods of the broker that perform
> that to the TransactionImpl. That's just a quick and ugly hack but works. 
>  


Thanks for your patch. I will have a look at this issue


>  
> 2. Object A holds a collection of Bs. Auto-Update is set to true in the
> repository. I create A and lock it, than I create some Bs, lock them and add
> them to A's collection. On commit the ObjectEnvelopeTable first stores A
> which also stores it's collections. Afterwards the ObjectEnvelopeTable goes
> through the ObjectEnvelopes of all Bs. All of these Bs have a StateNewDirty
> which always creates INSERT statements. But the Bs have already been stored
> as part of A's collection.
>  
> I currently do not have the time to provide a proper fix for this ( I just
> switched of AutoUpdate and it worked for me).
>  


Auto-Update and -Delete *must not* be set to true if working with the 
ODMG Implementation. There is no fix for this, it just does not work!
This is stated in http://objectbridge.sf.net/tutorial3.html#cascading.

cu,

Thomas


> Regards
> Rainer
>  
>  
> 

[OJB-developers] Bug in ODMG transaction

[Bischof, R. <rai...@ed...>]

Hi,
 
I just moved to the current release which should fix some bugs with foreign
keys and the ODMG interface. I discovered two more:
 
1. Object A references Object B of a different class in a 1-1 relationship.
A's PK consists only of the reference to B (i.e. B's PK, which is
auto-incremented). Both objects are newly created and properly locked with
the ODMG transaction. B's PK is incremented at that time but A's FK to B is
not updated at that time (this is done only in broker.store). Therefore A's
FK to B is 0 which does not work. OJB places a lock on an object whose PK is
not yet defined.
Solution: FKs must be assigned before the lock is performed. I modified the
TransactionImpl to do this by copying the methods of the broker that perform
that to the TransactionImpl. That's just a quick and ugly hack but works. 
 
 
2. Object A holds a collection of Bs. Auto-Update is set to true in the
repository. I create A and lock it, than I create some Bs, lock them and add
them to A's collection. On commit the ObjectEnvelopeTable first stores A
which also stores it's collections. Afterwards the ObjectEnvelopeTable goes
through the ObjectEnvelopes of all Bs. All of these Bs have a StateNewDirty
which always creates INSERT statements. But the Bs have already been stored
as part of A's collection.
 
I currently do not have the time to provide a proper fix for this ( I just
switched of AutoUpdate and it worked for me).
 
Regards
Rainer