objectbridge-developers — public list for developer issues

[OJB-developers] [status] moving ojb to apache

[Martin P. <mpo...@ma...>]

ojb is accepted as an apache project :-)

there is some discussion on the general@jakarta.apache.or list if it makes sense to start a new 
'main' project (something like db.apache.org which includes all db-related projects)
ojb would be the leading app (like tomcat for jakarta)

db.apache.org will have it's own PMC, site, ...

other candidates for db.apache.org are:
- torque http://jakarta.apache.org/turbine/torque
- axion http://axion.tigris.org/servlets/ProjectHome
- db pools from jakarta-commons

what do you think??

do you prefere to move ojb to jakarta.apache or db.apache???

martin


Geir wrote at ge...@ja...:
 > I have no idea why they want to move here, but to me, being the 'marquee'
 > project in a new Apache subproject has incredible upside for a project
 > trying to establish 'mindshare' in what seems to be a confusing vertical.
 > No doubt, being part of Jakarta is too.  But I would bet that in the
 > industry "Apache creates new subproject" is going to get a lot more
 > attention than "XXX joins Jakarta".

Re: [OJB-developers] bug in ProxyCollection

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

hi georg,

you're right, the broker is released while RsIterator still uses it.
i moved the release of the broker behind the iteration.

jakob

----- Original Message -----
From: "Georg Schneider" <ge...@me...>
To: <jbr...@ho...>
Cc: <obj...@li...>
Sent: Friday, May 03, 2002 10:16 AM
Subject: [OJB-developers] bug in ProxyCollection


> Hi Jacob,
>
> I think there is a bug in ProxyCollection where a broker is released to
> the pool and then still used. This has the effect that another thread can
> get hold of the same broker and thus screw things up. The RsIterator still
> holds a reference to the broker and uses it.
>
> It's happening in method protected void load():
>
>
>     if (!isEmpty())
>      {
>       Iterator iter = getBroker().getIteratorByQuery(getQuery());
>
> ==> PersistenceBrokerFactory.releaseInstance(getBroker());
>         setBroker(null);
>
> ==> will still be used here
>         while (iter.hasNext())
>         {
>           result.add(iter.next());
>         }
>     .....
>
>
> Cheers
>
> Georg
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: [OJB-developers] SQLGenerator

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

hi oleg,

i've now fixed multi segment path expressions ie:  owner.phone.number = ?

jakob 

AW: [OJB-developers] sql syntax optimalisation hints

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

Hi,

> -----Urspr=FCngliche Nachricht-----
> Von: bram [mailto:br...@in...]
> Gesendet: Freitag, 3. Mai 2002 00:44
> An: obj...@li...
> Betreff: [OJB-developers] sql syntax optimalisation hints
>=20
>=20
> Hi,
>=20
> Is there a way to add optimalisation hints (database dependend) to =
the
> query's?
>=20

currently not.

>=20
> Like the rule in oracle
>=20
> select /*+ rule*/ [colomn list] from [table list]
>=20
> Where rule is for example "HASH_AJ" or "INDEX( tab index )"
>=20
>=20
>=20
> Or the "options" in MsSQl2k
>=20
> Select * from a, b, c
> Option(force order, loop join)
>=20
>=20

The difficult thing will be to find an abstraction for those options.
Is it really worth the effort?
It's already possible to use OJBs QueryBySQL to encapsulate user =
defined SQL
code.

just my 0.02 EUR,

Thomas

>=20
>=20
> I know that the SqlGenerator generates sql92 compliant sql=20
> and that the
> database dependancies are minimalized to type mappings (eg BIT to int
> for MySql), but if with some pointers I could do it my self
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________________________
>=20
> Have big pipes? SourceForge.net is looking for download=20
> mirrors. We supply
> the hardware. You get the recognition. Email Us:=20
> ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

AW: [OJB-developers] JCA Commit time?

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

Hi Matthew,

> -----Urspr=FCngliche Nachricht-----
> Von: Matthew Baird [mailto:ma...@so...]
> Gesendet: Freitag, 3. Mai 2002 06:42
> An: ojb
> Betreff: [OJB-developers] JCA Commit time?
>=20
>=20
> I've been using the JCA for our porting from Castor to OJB=20
> project for a
> while, and it seems pretty stable. I'm sure there are some=20
> issues left in
> it, and it doesn't have XA support yet, but it's certainly=20
> stable enough for
> people to start to use and report bugs against. Should I=20
> commit it now?
>=20

YES !!!

> Before checking in code, please assure that all things=20
> compile and that all
> JUnit tests pass successfully.
>=20
> > No real JUnit tests for this piece, but the sample EJB=20
> works for CRUD=20
> > operations and OQL queries (essentially the ODMG interface)
>=20

OK!

> Before checking in code please check for conflicts with=20
> checkins of others.
> IDEs like eclipse will help you to merge things together.=20
> Before commiting
> merged files please again check 1.)
>=20
> > All new, so no conflicts.
>=20

OK!

> If you are checking in code that implements new features, please also
> provide JUnit Testcases that validate the new functionality.=20
> If the new features are visible to the end-user please also=20
> add (or modify)
> documentation.
>=20
> > I will provide documentation on how to use it.=20

That's good !

>I guess I=20
> could write=20
> > some JUnit test cases that work against an application server using =

> > the JCA, but this would mean reliance on some app server, and a=20
> > significant increase in unit test complexity. Any thoughts?
>=20

I think providing sample code for JBOSS + documentation is sufficient =
to get
users of other app-servers started.

thanks,

Thomas

AW: [OJB-developers] conversion strategy for extent classes

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

Hi,

> -----Urspr=FCngliche Nachricht-----
> Von: Jakob Braeuchi [mailto:jbr...@ho...]
> Gesendet: Donnerstag, 2. Mai 2002 21:46
> An: obj...@li...
> Betreff: [OJB-developers] conversion strategy for extent classes
>=20
>=20
> hi,
>=20
> while cleaning up the Article-samples i found that the=20
> conversionStrategy
> defined in the base class is not propagated to the extents.=20
> the extents both
> have the default conversion strategy:
>=20
>       <class.name>test.ojb.broker.Article</class.name>
>       ...
>       <class.extent>test.ojb.broker.BookArticle</class.extent>
>       <class.extent>test.ojb.broker.CdArticle</class.extent>
>       ...
>=20
> <conversionStrategy>test.ojb.broker.ArticleConversionStrategy<
/conversionStr
> ategy>
>=20
> is this by design ?
Yes, there is no implicit inheritance propagation in the metadata =
layer.
everything must be declared in the concrete classes!

Of course the semantics could also be changed, but I don't know if it's
worth the effort.

Thomas

>=20
> jakob
>=20
> _______________________________________________________________
>=20
> Have big pipes? SourceForge.net is looking for download=20
> mirrors. We supply
> the hardware. You get the recognition. Email Us:=20
> ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

[OJB-developers] bug in ProxyCollection

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

Hi Jacob,

I think there is a bug in ProxyCollection where a broker is released to
the pool and then still used. This has the effect that another thread can
get hold of the same broker and thus screw things up. The RsIterator still
holds a reference to the broker and uses it.

It's happening in method protected void load():


    if (!isEmpty())
     {
      	Iterator iter = getBroker().getIteratorByQuery(getQuery());

==>	PersistenceBrokerFactory.releaseInstance(getBroker());
        setBroker(null);

==> will still be used here
        while (iter.hasNext())
        {
          result.add(iter.next());
        }
    .....


Cheers

Georg

Re: [OJB-developers] SQLGenerator

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

hi oleg,

i did the original path expression to build joins and so i'm responsible for
all it's limitations ;-)
one issue is the type of the join (LEFT, RIGHT etc.).
today selection criteria and report queries provides no way to define
join-type.
we could define it in the path:

-  konti+.saldo (OUTER)       or in the criteria
- crit.addGreaterThan("konti.saldo", new Integer(100), OUTER);

do you have other ideas ?


jakob

----- Original Message -----
From: "Oleg Nitz" <on...@uk...>
To: <obj...@li...>
Sent: Thursday, May 02, 2002 11:29 PM
Subject: Re: [OJB-developers] SQLGenerator


> Thanks Bram!
>
> Oleg
>
> On Thursday 02 May 2002 22:21, you wrote:
> > Examples
> >
> > Tables:
> > A(id int, name varchar(10))
> > B(id int, value varchar(10))
> >
> > Records A
> > 1, "name1"
> > 2, "name2"
> >
> > Records B
> > 1, "value1"
> >
> >
> >
> >
> > Sql92:
> > Works with Mssql70, Mssql2000, postgresql, oracle 9(not checked, but
> > dba-er says it works)
> >
> > Select a.name, b.value
> > From a left outer join b on (a.id = b.id)
> >
> > Result:
> > Name1, value1
> > Name2, null
> >
> > Ms sqlserver 6.5/7.0/2000 syntax
> >
> > Select a.name, b.value
> > From a , b
> > where a.id *= b.id
> >
> > Result:
> > Name1, value1
> > Name2, null
> >
> >
> > Oracle 8
> > Select a.name, b.value
> > From a , b
> > where a.id = b.id (+)
> >
> > Result:
> > Name1, value1
> > Name2, null
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: [OJB-developers] n:m-Mapping with Extent

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

hi amit,

i just commited a quick fix for this issue.
it works with joachim sauer's testcase and passes all other tests, but it's
a QUICK fix.
the fix _modifies_ the MtoN-Query when working with extents.

jakob

----- Original Message -----
From: "Amit Gollapudi" <ago...@de...>
To: <obj...@li...>
Sent: Thursday, May 02, 2002 9:34 PM
Subject: RE: [OJB-developers] n:m-Mapping with Extent


Is there a patch available for this bug?  This is wreaking major havoc
on our project.

Amit

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...]
Sent: Tuesday, April 30, 2002 11:55 AM
To: obj...@li...;
Joa...@tp...
Subject: Re: [OJB-developers] n:m-Mapping with Extent


hi joachim,

a clean approach would be to have  a method in QueryFactory with a query
and
a class as parameters.
the factory should then return a clone (how deep ?) of the query with
all
criteria and tables etc. based on the new class.

greetings jakob


----- Original Message -----
From: <Joa...@tp...>
To: <obj...@li...>
Sent: Tuesday, April 30, 2002 9:48 AM
Subject: Re: [OJB-developers] n:m-Mapping with Extent


>
> Hy,
>
> I've already done what you suggested (rebuild a new query), but it was
a
> very ugly hack, as I didn't know where to put it and how to do it
properly
> ( I don't even want to mention were I did it ;-). It broke some other
tests
> 'though and I decided to do a clean approach, rather then debug this
ugly
> piece of code that I produced. At least I saw that extents in
combination
> with MtoN-mappings are possible. Is it possible to provide
> QueryByMtoNCriteria with the necessary information to rebuild itself
for a
> specific extent-class/table? I think that would be somewhat nicer.
>
> regards
> Joachim Sauer
>
>
>
>
>                     "Jakob
>                     Braeuchi"            An:
<obj...@li...>,
<Joa...@tp...>
>                     <jbraeuchi@ho        Kopie:
>                     tmail.com>           Thema:  Re: [OJB-developers]
n:m-Mapping with Extent
>
>                     30.04.2002
>                     09:08
>
>
>
>
>
> hi joachim,
>
> as you mentioned the problem is the wrong table in from- and
where-clause
> coming from prebuilt MtoNQuery.
> the second problem is getPreparedSelectStatement() in SqlGenerator:
for
> MtoNQQueries tables are taken from the query and NOT from
> the ClassDescriptor, the query still pointing to the tables of the
base
> class instead of the extent. the same is true for the
EqualToColumnCriteria
> in the query.
>
> i think when using extents there is always a mismatch between the
query
and
> the class descriptor but it only hurts with MtoNQuery.
> it may be the best thing to build a new query based on the original
one
for
> the extents and then to execute this query.
> what do you think ?
>
> jakob
>
>
> ----- Original Message -----
> From: <Joa...@tp...>
> To: <obj...@li...>
> Sent: Monday, April 29, 2002 3:04 PM
> Subject: [OJB-developers] n:m-Mapping with Extent
>
>
> > Hy,
> >
> > it's me again. I've finally hunted down the bug. Let me explain the
> > scenario:
> >
> > I've got a class OneSide. Each object can have one or more ManySide
> > objects. This is implemented via a List with coresponding
> > CollectionDescriptor using a association-table (non-decomposed
> N:M-Mapping
> > in OJB-speak). Additionally there is a class named ManySideExtent,
that
> > extends ManySide and is mapped to another table.
> >
> > When I enable debugging in SqlGenerator I'll find the following
messages
> > (after many others)  when loading a OneSide object:
> >
> > [ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: SELECT
> > manyside.id,manyside.value FROM manyside, oneside_manyside WHERE
> > (oneside_id= ? )  AND oneside_manyside.manyside_id=manyside.id
> >
> > this one looks quite correct and gets me the correct results (all
> ManySide
> > objects that belong to the one OneSide object), but the next one
(which
> > tries to load the ManySideExtent objects) fails:
> >
> > [ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: SELECT
> >
manyside_extent.id,manyside_extent.value,manyside_extent.another_value
> FROM
> > manyside, oneside_manyside WHERE (oneside_id= ? )  AND
> > oneside_manyside.manyside_id=manyside.id
> >
> > the problem here obviously is, that the wrong table is used in the
> > FROM-clause and the WHERE-clause. These come from the Query object,
that
> is
> > created by the PersistenceBrokerImpl in getMtoNQuery. I think
calling
> > getMtoNQuery with the ClassDescriptor of ManySideExtent for the
second
> > query would solve the problem, the problem is, that the query is not
> built
> > in the function that decides wether we need to query for extents ...
> >
> > Maybe a correct solution would be somewhere else altogether, but I
don't
> > know enough about the system to see where.
> >
> > regards
> > Joachim Sauer
> >
> >
> > _______________________________________________
> > 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
>

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

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] JCA Commit time?

[Matthew B. <ma...@so...>]

I've been using the JCA for our porting from Castor to OJB project for a
while, and it seems pretty stable. I'm sure there are some issues left in
it, and it doesn't have XA support yet, but it's certainly stable enough for
people to start to use and report bugs against. Should I commit it now?

Before checking in code, please assure that all things compile and that all
JUnit tests pass successfully.

> No real JUnit tests for this piece, but the sample EJB works for CRUD 
> operations and OQL queries (essentially the ODMG interface)

Before checking in code please check for conflicts with checkins of others.
IDEs like eclipse will help you to merge things together. Before commiting
merged files please again check 1.)

> All new, so no conflicts.

If you are checking in code that implements new features, please also
provide JUnit Testcases that validate the new functionality. 
If the new features are visible to the end-user please also add (or modify)
documentation.

> I will provide documentation on how to use it. I guess I could write 
> some JUnit test cases that work against an application server using 
> the JCA, but this would mean reliance on some app server, and a 
> significant increase in unit test complexity. Any thoughts?

[OJB-developers] SQL Server Support

[Matthew B. <ma...@so...>]

17:10:51,663 INFO  [STDOUT] [DEFAULT] INFO:
17:10:51,663 INFO  [STDOUT] problems with platform
ojb.broker.platforms.PlatformMsSQLServer2000Impl:
ojb.broker.platforms.PlatformMsSQLServer2000Impl
17:10:51,663 INFO  [STDOUT] [DEFAULT] INFO:

didn't there used to be a MsSQLServer2000 platform? 

[OJB-developers] moving ojb to jakarta

[Martin P. <mpo...@ma...>]

ojb is accepted as a new apache projects (there is one vote missing, but we got 6 of 6 votes so far :-)

there is some discussion on ge...@ja... to find the 'right place' for ojb
feel free to join the list and discussion

i started to convert the docs to xdocs (the format all docs at jakarta are written in)
i'll check them in tomorrow and make the generated site available for public review

there are some task left before we can move to jakarta:

- we should decide which coding conventions should be used
i propos to use http://jakarta.apache.org/turbine/common/code-standards.html

- the packages will be renamed to org.apache.ojb

i'll do the package renaming and import the sources as soon as the repo ist ready and i get the ok 
from the ojb developers ;-)
i'll also make the code match the coding conventions (so we need a decision soon)



martin

RE: [OJB-developers] sql syntax optimalisation hints

[Matthew B. <ma...@so...>]

We've been talking about this at work, and it's something we *eventually*
want to do.

I think this is more complex than general SQL tweaking to support different
platforms, as you need to map the "common" bits of the hints to a general
syntax or set of object attributes.

Who has the expertise to figure out this part? Bram, sounds like you might
be the man :)

m

-----Original Message-----
From: bram [mailto:br...@in...] 
Sent: Thursday, May 02, 2002 3:44 PM
To: obj...@li...
Subject: [OJB-developers] sql syntax optimalisation hints

Hi,

Is there a way to add optimalisation hints (database dependend) to the
query's?


Like the rule in oracle

select /*+ rule*/ [colomn list] from [table list]

Where rule is for example "HASH_AJ" or "INDEX( tab index )"



Or the "options" in MsSQl2k

Select * from a, b, c
Option(force order, loop join)




I know that the SqlGenerator generates sql92 compliant sql and that the
database dependancies are minimalized to type mappings (eg BIT to int
for MySql), but if with some pointers I could do it my self







_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] sql syntax optimalisation hints

[bram <br...@in...>]

Hi,

Is there a way to add optimalisation hints (database dependend) to the
query's?


Like the rule in oracle

select /*+ rule*/ [colomn list] from [table list]

Where rule is for example "HASH_AJ" or "INDEX( tab index )"



Or the "options" in MsSQl2k

Select * from a, b, c
Option(force order, loop join)




I know that the SqlGenerator generates sql92 compliant sql and that the
database dependancies are minimalized to type mappings (eg BIT to int
for MySql), but if with some pointers I could do it my self

Re: AW: [OJB-developers] SQLGenerator

[Oleg N. <on...@uk...>]

Hi Thomas,

On Thursday 02 May 2002 21:14, Thomas Mahler wrote:
> Hi again,
>
> Oleg Nitz wrote:
> > On Thursday 02 May 2002 18:13, Mahler Thomas wrote:
> >>>2) OJB doesn't support queries on columns with path longer than 1,
> >>>i.e. it successfully handles
> >>>            crit.addEqualTo("source.name", "A");
> >>>but fails on
> >>>            crit.addGreaterThan("source.location.x", new Integer(0));
> >>
> >>Oh, I thought this was possible. If this does not work it should be fixed
> >> !
> >
> > I wrote the testcase and can commit it.
>
> fine !
Done. The GraphTest for now is commented out in broker/AllTests.java

Oleg

Re: [OJB-developers] SQLGenerator

[Oleg N. <on...@uk...>]

Thanks Bram!

Oleg

On Thursday 02 May 2002 22:21, you wrote:
> Examples
>
> Tables:
> A(id int, name varchar(10))
> B(id int, value varchar(10))
>
> Records A
> 1, "name1"
> 2, "name2"
>
> Records B
> 1, "value1"
>
>
>
>
> Sql92:
> Works with Mssql70, Mssql2000, postgresql, oracle 9(not checked, but
> dba-er says it works)
>
> 	Select a.name, b.value
> 	From a left outer join b on (a.id = b.id)
>
> 	Result:
> 	Name1, value1
> 	Name2, null
>
> Ms sqlserver 6.5/7.0/2000 syntax
>
> 	Select a.name, b.value
> 	From a , b
> 	where a.id *= b.id
>
> 	Result:
> 	Name1, value1
> 	Name2, null
>
>
> Oracle 8
> 	Select a.name, b.value
> 	From a , b
> 	where a.id = b.id (+)
>
> 	Result:
> 	Name1, value1
> 	Name2, null

[OJB-developers] conversion strategy for extent classes

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

hi,

while cleaning up the Article-samples i found that the conversionStrategy
defined in the base class is not propagated to the extents. the extents both
have the default conversion strategy:

      <class.name>test.ojb.broker.Article</class.name>
      ...
      <class.extent>test.ojb.broker.BookArticle</class.extent>
      <class.extent>test.ojb.broker.CdArticle</class.extent>
      ...

<conversionStrategy>test.ojb.broker.ArticleConversionStrategy</conversionStr
ategy>

is this by design ?

jakob

RE: [OJB-developers] n:m-Mapping with Extent

[Amit G. <ago...@de...>]

Is there a patch available for this bug?  This is wreaking major havoc
on our project.

Amit

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...]
Sent: Tuesday, April 30, 2002 11:55 AM
To: obj...@li...;
Joa...@tp...
Subject: Re: [OJB-developers] n:m-Mapping with Extent


hi joachim,

a clean approach would be to have  a method in QueryFactory with a query
and
a class as parameters.
the factory should then return a clone (how deep ?) of the query with
all
criteria and tables etc. based on the new class.

greetings jakob


----- Original Message -----
From: <Joa...@tp...>
To: <obj...@li...>
Sent: Tuesday, April 30, 2002 9:48 AM
Subject: Re: [OJB-developers] n:m-Mapping with Extent


>
> Hy,
>
> I've already done what you suggested (rebuild a new query), but it was
a
> very ugly hack, as I didn't know where to put it and how to do it
properly
> ( I don't even want to mention were I did it ;-). It broke some other
tests
> 'though and I decided to do a clean approach, rather then debug this
ugly
> piece of code that I produced. At least I saw that extents in
combination
> with MtoN-mappings are possible. Is it possible to provide
> QueryByMtoNCriteria with the necessary information to rebuild itself
for a
> specific extent-class/table? I think that would be somewhat nicer.
>
> regards
> Joachim Sauer
>
>
>
>
>                     "Jakob
>                     Braeuchi"            An:
<obj...@li...>,
<Joa...@tp...>
>                     <jbraeuchi@ho        Kopie:
>                     tmail.com>           Thema:  Re: [OJB-developers]
n:m-Mapping with Extent
>
>                     30.04.2002
>                     09:08
>
>
>
>
>
> hi joachim,
>
> as you mentioned the problem is the wrong table in from- and
where-clause
> coming from prebuilt MtoNQuery.
> the second problem is getPreparedSelectStatement() in SqlGenerator:
for
> MtoNQQueries tables are taken from the query and NOT from
> the ClassDescriptor, the query still pointing to the tables of the
base
> class instead of the extent. the same is true for the
EqualToColumnCriteria
> in the query.
>
> i think when using extents there is always a mismatch between the
query
and
> the class descriptor but it only hurts with MtoNQuery.
> it may be the best thing to build a new query based on the original
one
for
> the extents and then to execute this query.
> what do you think ?
>
> jakob
>
>
> ----- Original Message -----
> From: <Joa...@tp...>
> To: <obj...@li...>
> Sent: Monday, April 29, 2002 3:04 PM
> Subject: [OJB-developers] n:m-Mapping with Extent
>
>
> > Hy,
> >
> > it's me again. I've finally hunted down the bug. Let me explain the
> > scenario:
> >
> > I've got a class OneSide. Each object can have one or more ManySide
> > objects. This is implemented via a List with coresponding
> > CollectionDescriptor using a association-table (non-decomposed
> N:M-Mapping
> > in OJB-speak). Additionally there is a class named ManySideExtent,
that
> > extends ManySide and is mapped to another table.
> >
> > When I enable debugging in SqlGenerator I'll find the following
messages
> > (after many others)  when loading a OneSide object:
> >
> > [ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: SELECT
> > manyside.id,manyside.value FROM manyside, oneside_manyside WHERE
> > (oneside_id=3D ? )  AND oneside_manyside.manyside_id=3Dmanyside.id
> >
> > this one looks quite correct and gets me the correct results (all
> ManySide
> > objects that belong to the one OneSide object), but the next one
(which
> > tries to load the ManySideExtent objects) fails:
> >
> > [ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: SELECT
> >
manyside_extent.id,manyside_extent.value,manyside_extent.another_value
> FROM
> > manyside, oneside_manyside WHERE (oneside_id=3D ? )  AND
> > oneside_manyside.manyside_id=3Dmanyside.id
> >
> > the problem here obviously is, that the wrong table is used in the
> > FROM-clause and the WHERE-clause. These come from the Query object,
that
> is
> > created by the PersistenceBrokerImpl in getMtoNQuery. I think
calling
> > getMtoNQuery with the ClassDescriptor of ManySideExtent for the
second
> > query would solve the problem, the problem is, that the query is not
> built
> > in the function that decides wether we need to query for extents ...
> >
> > Maybe a correct solution would be somewhere else altogether, but I
don't
> > know enough about the system to see where.
> >
> > regards
> > Joachim Sauer
> >
> >
> > _______________________________________________
> > 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
>

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

RE: [OJB-developers] SQLGenerator

[bram <br...@in...>]

Examples

Tables:
A(id int, name varchar(10))
B(id int, value varchar(10))

Records A
1, "name1"
2, "name2"

Records B
1, "value1"




Sql92:
Works with Mssql70, Mssql2000, postgresql, oracle 9(not checked, but
dba-er says it works)

	Select a.name, b.value
	From a left outer join b on (a.id = b.id)

	Result:
	Name1, value1
	Name2, null

Ms sqlserver 6.5/7.0/2000 syntax

	Select a.name, b.value
	From a , b
	where a.id *= b.id

	Result:
	Name1, value1
	Name2, null


Oracle 8
	Select a.name, b.value
	From a , b
	where a.id = b.id (+)

	Result:
	Name1, value1
	Name2, null

Re: [OJB-developers] SQLGenerator

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

hi thomas, oleg,

i implemented only sql-92 join syntax, because the join clause is cleanly
separated from the FROM- and the WHERE-clause. i agree that this may be a
candidate for platform specific code but i also think that 92 is a long time
ago...

jakob

----- Original Message -----
From: "Mahler Thomas" <tho...@it...>
To: "'Oleg Nitz'" <on...@uk...>;
<obj...@li...>
Sent: Thursday, May 02, 2002 5:13 PM
Subject: AW: [OJB-developers] SQLGenerator


> Hi Oleg,
>
> > -----Ursprungliche Nachricht-----
> > Von: Oleg Nitz [mailto:on...@uk...]
> > Gesendet: Donnerstag, 2. Mai 2002 16:36
> > An: obj...@li...
> > Betreff: [OJB-developers] SQLGenerator
> >
> >
> > Hi,
> >
> > I started to work on the "OQL Self Joins" issue
> >
> > http://sourceforge.net/forum/forum.php?thread_id=655922&forum_id=43066
> > so I am looking at the SQLGenerator stuff, and its
> > capabilities seem a bit
> > restricted. Please, confirm the following statements
> > 1) OJB supports only databases that support SQL-92 JOIN
> > syntax (INNER JOIN,
> > LEFT OUTER JOIN).
>
> Right !
>
> > Thus Sybase ASE and MS SQL Server aren't supported, since
> > they don't support
> > SQL-92 JOIN syntax AFAIK. Does Oracle support it? Not sure.
>
> AFAIK Oracle 8i doesn't but 9i does.
>
> > I suppose that generating of join syntax should be delegated
> > to Platform
> > implementations.
>
> I agree.
>
> > 2) OJB doesn't support queries on columns with path longer than 1,
> > i.e. it successfully handles
> >             crit.addEqualTo("source.name", "A");
> > but fails on
> >             crit.addGreaterThan("source.location.x", new Integer(0));
> >
>
> Oh, I thought this was possible. If this does not work it should be fixed
!
>
> > I can try to solve these issues too.
>
> That would be great !
>
> Thanks,
>
> Thomas
>
> >
> > Regards,
> >  Oleg
> >
> > _______________________________________________________________
> >
> > Have big pipes? SourceForge.net is looking for download
> > mirrors. We supply
> > the hardware. You get the recognition. Email Us:
> > ban...@so...
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: AW: [OJB-developers] SQLGenerator

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

Hi again,

Oleg Nitz wrote:

> On Thursday 02 May 2002 18:13, Mahler Thomas wrote:
> 
>>>2) OJB doesn't support queries on columns with path longer than 1,
>>>i.e. it successfully handles
>>>            crit.addEqualTo("source.name", "A");
>>>but fails on
>>>            crit.addGreaterThan("source.location.x", new Integer(0));
>>>
>>Oh, I thought this was possible. If this does not work it should be fixed !
>>
> I wrote the testcase and can commit it.


fine !


> 
>>>I can try to solve these issues too.
>>>
>>That would be great !
>>
> Okay. I hope nobody else is now working on this piece of code. Probably I 
> will also touch Query related code.
> 


I recommend using eclipse. It will help you merging code against 
previous changes of other developers.

But AFAIK there is currently no one else working in this area.

cheers,

Thomas


> Oleg
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: [OJB-developers] build junit

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

Hi Oleg, Hi Jakob, Hi Matthew,

My fault again! I'm using JDK 1.4. In Jdk1.4 java.lang.reflect.Field is 
serializable. In Jdk 1.3 and lower it's not!

After setting the attribute PersistentFieldDefaultImpl.field to 
transient everything should be fine under JDK 1.3 too now.

Oleg: I also applied your patch.

thanks !

Thomas

Oleg Nitz wrote:

> Thomas, it still fails with the same error.
> I propose the following patch, which solves the problem:
> 
> Index: RepositoryPersistor.java
> ===================================================================
> RCS file: 
> /cvsroot/objectbridge/ojb-1-0/src/java/ojb/broker/metadata/RepositoryPersistor.java,v
> retrieving revision 1.5
> diff -c -r1.5 RepositoryPersistor.java
> *** RepositoryPersistor.java    2 May 2002 05:06:05 -0000       1.5
> --- RepositoryPersistor.java    2 May 2002 10:34:46 -0000
> ***************
> *** 102,108 ****
>           else
>           {
>               DescriptorRepository result = buildRepository(filename);
> !             serialize(result, serFile);
>               return result;
>           }
>       }
> --- 102,111 ----
>           else
>           {
>               DescriptorRepository result = buildRepository(filename);
> !             if (useSerializedFile)
> !             {
> !                 serialize(result, serFile);
> !             }
>               return result;
>           }
>       }
> 
> May I commit it?
> 
> Oleg
> 
> On Thursday 02 May 2002 08:08, you wrote:
> 
>>Hi Oleg,
>>
>>SOrry, that was my fault. I checked in some hacked stuff.
>>I fixed it over the last two days. So if you get the latest stuff from
>>CVS everything should run smooth now.
>>
> 
> 
> 

Re: AW: [OJB-developers] SQLGenerator

[Oleg N. <on...@uk...>]

On Thursday 02 May 2002 18:13, Mahler Thomas wrote:
> > 2) OJB doesn't support queries on columns with path longer than 1,
> > i.e. it successfully handles
> >             crit.addEqualTo("source.name", "A");
> > but fails on
> >             crit.addGreaterThan("source.location.x", new Integer(0));
>
> Oh, I thought this was possible. If this does not work it should be fixed !
I wrote the testcase and can commit it.

>
> > I can try to solve these issues too.
>
> That would be great !
Okay. I hope nobody else is now working on this piece of code. Probably I 
will also touch Query related code.

Oleg

Re: [OJB-developers] SQLGenerator

[Oleg N. <on...@uk...>]

Thanks Charles,

I wasn't really aware of MS SQL syntax, I just thought that it should be much 
like Sybase ASE, for historical reasons :)

Oleg


On Thursday 02 May 2002 17:37, Charles Anthony wrote:
> MS SQL 7 seems to support SQL-92 JOIN syntax: the following is the syntax
> of the FOR clause from the transact-sql help file...
>
> [ FROM {<table_source>} [,...n] ]
>
> <table_source> ::=
> 	table_name [ [AS] table_alias ] [ WITH ( <table_hint> [,...n]) ]
>
> 	| view_name [ [AS] table_alias ]
> 	| rowset_function [ [AS] table_alias ]
> 	| derived_table [AS] table_alias [ (column_alias [,...n] ) ]
> 	| <joined_table>
>
> <joined_table> ::=
> 	<table_source> <join_type> <table_source> ON <search_condition>
>
> 	| <table_source> CROSS JOIN <table_source>
> 	| <joined_table>
>
> <join_type> ::=
> 	[ INNER | { { LEFT | RIGHT | FULL } [OUTER] } ]
> 	[ <join_hint> ]
> 	JOIN
>
> Cheers,
>
> Charles.
>
> > -----Original Message-----
> > From: Oleg Nitz [mailto:on...@uk...]
> > Sent: 02 May 2002 15:36
> > To: obj...@li...
> > Subject: [OJB-developers] SQLGenerator
> >
> >
> > Hi,
> >
> > I started to work on the "OQL Self Joins" issue
> >
> > http://sourceforge.net/forum/forum.php?thread_id=655922&forum_id=43066
> > so I am looking at the SQLGenerator stuff, and its
> > capabilities seem a bit
> > restricted. Please, confirm the following statements
> > 1) OJB supports only databases that support SQL-92 JOIN
> > syntax (INNER JOIN,
> > LEFT OUTER JOIN).
> > Thus Sybase ASE and MS SQL Server aren't supported, since
> > they don't support
> > SQL-92 JOIN syntax AFAIK. Does Oracle support it? Not sure.
> > I suppose that generating of join syntax should be delegated
> > to Platform
> > implementations.
> > 2) OJB doesn't support queries on columns with path longer than 1,
> > i.e. it successfully handles
> >             crit.addEqualTo("source.name", "A");
> > but fails on
> >             crit.addGreaterThan("source.location.x", new Integer(0));
> >
> > I can try to solve these issues too.
> >
> > Regards,
> >  Oleg
> >
> > _______________________________________________________________
> >
> > Have big pipes? SourceForge.net is looking for download
> > mirrors. We supply
> > the hardware. You get the recognition. Email Us:
> > ban...@so...
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> This email and any attachments are strictly confidential and are intended
> solely for the addressee. If you are not the intended recipient you must
> not disclose, forward, copy or take any action in reliance on this message
> or its attachments. If you have received this email in error please notify
> the sender as soon as possible and delete it from your computer systems.
> Any views or opinions presented are solely those of the author and do not
> necessarily reflect those of HPD Software Limited or its affiliates.
>
>  At present the integrity of email across the internet cannot be guaranteed
> and messages sent via this medium are potentially at risk.  All liability
> is excluded to the extent permitted by law for any claims arising as a re-
> sult of the use of this medium to transmit information by or to
> HPD Software Limited or its affiliates.
>
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] SQLGenerator

[Oleg N. <on...@uk...>]

On Thursday 02 May 2002 17:36, you wrote:
>=9AI'm not much of a DB guy, but I am pretty sure we're using the SQL-92=
 JOIN
>=9Asyntax in Oracle 9i. I think 8 and before, maybe 8i didn't support th=
at.

Thank you for the info. I also think that Oracle 8i doesn't support that.

Thanks,
=9AOleg