objectbridge-developers — public list for developer issues

Re: [OJB-developers] ODMG transaction question

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

Hi Matt,

> Matt Goodall wrote:
> 
> Hi,
> 
> I have found something which I can only describe as strange, perhaps
> there is a legitimate explanation or perhaps it's a bug.
> 
> First of all, some example code ...
> 
> Database schema:
> 
>     create table artist
>     (
>         id int not null,
>         name varchar2(100),
>         primary key (id),
>         unique (name)
>     )
> Code:
> 
>     Transaction tx = odmg.newTransaction();
>     tx.begin();
> 
>     Artist artist = new Artist();
>     artist.name = "xyz";
>     tx.lock(artist, Transaction.WRITE);
>     tx.checkpoint();
> 
>     OQLQuery query = odmg.newOQLQuery();
>     query.create("select allArtists from ojbtest.Artist");
>     Collection list = (Collection) query.execute();
>     Iterator it = list.iterator();
>     while(it.hasNext())
>     {
>         artist = (Artist) it.next();
>         System.out.println(artist);
>     }
> 
>     tx.commit();
> 
> The 1st time the code is run the checkpoint commits the artist to the
> database, as expected, and the "select allArtists" query returns the
> expected rows.
> 
> The 2nd time through, the unique(name) constraint means that the
> artist cannot be added but the checkpoint succeeds (!!!), the "select
> allArtists" returns the same objects that were seen the 1st time and,
> finally, an exception is thrown in tx.commit().
> 
> As a test I wrote almost the equivalent using the lower level OJB
> interface and everything worked as expected i.e. an exception was
> thrown as soon as I tried to add the same artist.
>
> Is this the correct behaviour or is it a bug?

This is definitively a bug in .checkpoint() !
I assume that exceptions thrown from the lower level PersistenceBroker
API are ignored or not handled correctly during .checkpoint().

> 
> I have to say, I'm not sure I'd ever use transactions like this, it
> all came about through some test code which *always* aborted the
> transaction. I didn't have the checkpoint() then either. The intention
> was to leave the database intact after running the test which addded
> data and then retrieved it again - I was just playing with the API
> basically.
> 

But even if it's no realistic scenario: OJB must handle it correctly!!!

Thanks for you detailed report, it will help me to fix this thing
quickly!

--Thomas

> Cheers, Matt
> ---
> Matt Goodall
> Analyst Programmer, Strategic Systems Solutions
> e: mat...@ss..., t: +44 113 3892645
>

[OJB-developers] ODMG transaction question

[Matt G. <mat...@ss...>]

Hi,

I have found something which I can only describe as strange, perhaps there
is a legitimate explanation or perhaps it's a bug.

First of all, some example code ...

Database schema:

    create table artist
    (
        id int not null,
        name varchar2(100),
        primary key (id),
        unique (name)
    )

Code:

    Transaction tx = odmg.newTransaction();
    tx.begin();

    Artist artist = new Artist();
    artist.name = "xyz";
    tx.lock(artist, Transaction.WRITE);
    tx.checkpoint();

    OQLQuery query = odmg.newOQLQuery();
    query.create("select allArtists from ojbtest.Artist");
    Collection list = (Collection) query.execute();
    Iterator it = list.iterator();
    while(it.hasNext())
    {
        artist = (Artist) it.next();
        System.out.println(artist);
    }

    tx.commit();

The 1st time the code is run the checkpoint commits the artist to the
database, as expected, and the "select allArtists" query returns the
expected rows.

The 2nd time through, the unique(name) constraint means that the artist
cannot be added but the checkpoint succeeds (!!!), the "select allArtists"
returns the same objects that were seen the 1st time and, finally, an
exception is thrown in tx.commit().

As a test I wrote almost the equivalent using the lower level OJB interface
and everything worked as expected i.e. an exception was thrown as soon as I
tried to add the same artist.

Is this the correct behaviour or is it a bug?

I have to say, I'm not sure I'd ever use transactions like this, it all came
about through some test code which *always* aborted the transaction. I
didn't have the checkpoint() then either. The intention was to leave the
database intact after running the test which addded data and then retrieved
it again - I was just playing with the API basically.

Cheers, Matt
---
Matt Goodall
Analyst Programmer, Strategic Systems Solutions
e: mat...@ss..., t: +44 113 3892645

[OJB-developers] Proposal for a OJB based JDO implementation

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

Hi all,

With the last release we have now implemented most of the OJB 1.0
features.
It's time to prpare for the future!

I have written a short proposal for the OJB JDO implementation.
You will find it at: 
http://objectbridge.sourceforge.net/jdo/jdo-proposal.html

I have already opened a special mailinglist for this new subproject:
http://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev

Everyone is invited to participate!

I'm looking forward to your comments and suggestions,

thanks,

Thomas

[OJB-developers] new release 0.7.277

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

Hi all,

I just published a new release.
Prominent new feature is support for Logging. I did not implement a
LOG4J based logger but provided an interface that will allow to use
LOG4J or JDK1.4 logging or whatsoever.
For the time being I'm providing a minimalistic implementation
"PoorMansLoggerImpl".
Logging is now configurable through the OJB.properties file.

Getting Proxies properly working with ODMG tranactions was quite tricky.
I had to introduce a new callback concept in The Proxy
IndirectionHandlers.

The most important change:
I had two complete code walkthroughs to refactor the Exception handling.
I hope that it will now throw all exceptions to user applications.
If you discover any mistakes or find that still some things don't work:
please drop me a line.

from the release notes:

new features:
- Provide full column name information  in ClassDescriptor
- Sortable 1:n associations
- Integrate LOG4J (must use the preprocessor to avoid logging in
production code)
- Integrate getUnique implementation from Jim
- Improve OQLQuery transaction handling if transaction was not opened 
- SELECT DISTINCT support from Jakob

bug fixes:
- ODMG commit must throw TransactionAbortedException if an abort occurs.
- Delete null references: bug
- Transactionimpl.register(...) does not work properly for Proxies
- Correct ODMG checkpoint semantics
- Don't hide exceptions during queries, updates and inserts but reach
them to client app !
- M:N bug: use full qualified column names
- Correct documentation regarding fk_descriptor_ids

refactorings:
- Cache synchronization
- JUNIT tests for Path expresseions
- Remove System.out.println() from JUNIT tests
- Improvements of RsIterator
- Introduce a GUID class

best regards,
and all the best to all of you for the new year!

Thomas

Re: [OJB-developers] OJB ManageableCollection ?

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

hi thomas,

thank you for clarification. i now understand the intention to have =
those collections and i'll try to find a way to support lazy collection =
there too. (eventually with a new interface ProxyManageableCollection)=20
i think the current implementation of ProxyCollection should not be used =
for ManageableCollection.

jakob
  ----- Original Message -----=20
  From: Mahler Thomas=20
  To: 'Jakob Braeuchi' ; Objectbridge Developers List (E-mail)=20
  Sent: Tuesday, December 18, 2001 9:11 AM
  Subject: AW: [OJB-developers] OJB ManageableCollection ?


  Hi Jakob,

  the ManageableCollection interface maybe helpful if you don't want to =
(or can't)  implement 1:n association with java.util.Collection derived =
classes or with arrays.
  A typical example are user defined typed collections. See sample code =
from package test.ojb.broker below. There is a ProductGroup class with a =
collection implementor=20
  allArticlesInGroup of type ArticleCollection.

  Class ArticleCollection only allows typed access (as opposed to the =
untyped access with java.util.Collection).
  You can add only InterfaceArticle objects and with get(...) you =
retrieve InterfaceArticle objects from the collection.

  OJB must interact with such user defined collections in a standardized =
way. That's the reason for the callback interface ManageableCollection. =
It provides elementary access to the user defined collection for the =
materialisation process and for update and delete routines (through =
ojbIterator()).

  HTH,

  Thomas

  public class ProductGroupWithTypedCollection
  {
      // ...

      /** collection containing all articles of a given product group*/
      private ArticleCollection allArticlesInGroup;

      // ...
  }

  public class ArticleCollection implements ManageableCollection
  {
      private Vector elements;

      /**
       * ArticleCollection constructor comment.
       */
      public ArticleCollection()
      {
          super();
          elements =3D new Vector();
      }

      public void add(InterfaceArticle article)
      {
          if (elements =3D=3D null)
              elements =3D new Vector();
          elements.add(article);
      }

      public InterfaceArticle get(int index)
      {
          return (InterfaceArticle) elements.get(index);
      }

      /**
       * add method comment.
       */
      public void ojbAdd(java.lang.Object anObject)
      {
          elements.add((InterfaceArticle) anObject);
      }

      /**
       * addAll method comment.
       */
      public void ojbAddAll(ojb.broker.ManageableCollection =
otherCollection)
      {
          elements.addAll(((ArticleCollection) =
otherCollection).elements);
      }

      /**
       * ojbIterator method comment.
       */
      public java.util.Iterator ojbIterator()
      {
          return elements.iterator();
      }

      public int size()
      {
          return elements.size();
      }

      public String toString()
      {
          return elements.toString();
      }
  }


    -----Urspr=FCngliche Nachricht-----
    Von: Jakob Braeuchi [mailto:jbr...@ho...]
    Gesendet: Dienstag, 18. Dezember 2001 08:33
    An: Objectbridge Developers List (E-mail)
    Betreff: [OJB-developers] OJB ManageableCollection ?


    hi,

    while working on the proxy-collection, i came across the =
ManageableCollection.
    i do not know what they are needed for, the three methods defined in =
this interface are also defined (without ojb prefix) in Collection.

    jakob

AW: [OJB-developers] OJB ManageableCollection ?

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

Hi Jakob,
=20
the ManageableCollection interface maybe helpful if you don't want to =
(or
can't)  implement 1:n association with java.util.Collection derived =
classes
or with arrays.
A typical example are user defined typed collections. See sample code =
from
package test.ojb.broker below. There is a ProductGroup class with a
collection implementor=20
allArticlesInGroup of type ArticleCollection.
=20
Class ArticleCollection only allows typed access (as opposed to the =
untyped
access with java.util.Collection).
You can add only InterfaceArticle objects and with get(...) you =
retrieve
InterfaceArticle objects from the collection.
=20
OJB must interact with such user defined collections in a standardized =
way.
That's the reason for the callback interface ManageableCollection. It
provides elementary access to the user defined collection for the
materialisation process and for update and delete routines (through
ojbIterator()).
=20
HTH,
=20
Thomas
=20
public class ProductGroupWithTypedCollection
{
    // ...
=20
    /** collection containing all articles of a given product group*/
    private ArticleCollection allArticlesInGroup;

    // ...
}
=20
public class ArticleCollection implements ManageableCollection
{
    private Vector elements;
=20
    /**
     * ArticleCollection constructor comment.
     */
    public ArticleCollection()
    {
        super();
        elements =3D new Vector();
    }
=20
    public void add(InterfaceArticle article)
    {
        if (elements =3D=3D null)
            elements =3D new Vector();
        elements.add(article);
    }
=20
    public InterfaceArticle get(int index)
    {
        return (InterfaceArticle) elements.get(index);
    }
=20
    /**
     * add method comment.
     */
    public void ojbAdd(java.lang.Object anObject)
    {
        elements.add((InterfaceArticle) anObject);
    }
=20
    /**
     * addAll method comment.
     */
    public void ojbAddAll(ojb.broker.ManageableCollection =
otherCollection)
    {
        elements.addAll(((ArticleCollection) =
otherCollection).elements);
    }
=20
    /**
     * ojbIterator method comment.
     */
    public java.util.Iterator ojbIterator()
    {
        return elements.iterator();
    }
=20
    public int size()
    {
        return elements.size();
    }
=20
    public String toString()
    {
        return elements.toString();
    }
}
=20
=20

-----Urspr=FCngliche Nachricht-----
Von: Jakob Braeuchi [mailto:jbr...@ho...]
Gesendet: Dienstag, 18. Dezember 2001 08:33
An: Objectbridge Developers List (E-mail)
Betreff: [OJB-developers] OJB ManageableCollection ?


hi,
=20
while working on the proxy-collection, i came across the
ManageableCollection.
i do not know what they are needed for, the three methods defined in =
this
interface are also defined (without ojb prefix) in Collection.
=20
jakob

[OJB-developers] OJB ManageableCollection ?

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

hi,

while working on the proxy-collection, i came across the =
ManageableCollection.
i do not know what they are needed for, the three methods defined in =
this interface are also defined (without ojb prefix) in Collection.

jakob

[OJB-developers] Re: Proposed Enhancement

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

Hi Jim,

Thanks for your interest in OJB!

Jim Eatmon wrote:
> 
> Hi Thomas,
> 
> First, let me thank you for all your efforts on
> ObjectRelationalBridge!
> 
> My app runs in a distributed fashion, and requires that
> following an insert of an object, the primary key values be
> returned so that the original instance of the object can be
> updated.  As the store(object) method returns void, I'd
> like to either 1:  change store(object) to return the
> object stored or 2:  or create a new method insert(object)
> that returns an Object array of the pk values by calling
> aClassdescriptor.getKeyValues(object) following the insert
> by the PersistenceBroker.
> 

Did you have a look at the class ojb.broker.Identity ?
It can do that stuff right now for you:

say we have an object person of Type Person:

Person person = ...;

now you can compute this objects identity by

Identity personOID = new Identity(person);

An Objects identity if defined by the name of the class and by the
values of the primary key attributes.

You can use this Identity to lookup the original Object by:
PersistenceBroker broker = ...;
Person originalObject = broker.getObjectByIdentity(personOID);

If you think you definitely must know the primarykey attributes of an
object, you can obtain an Array of the Objects primary key values by:
Object[] primaryKeys = personOID.getPrimaryKeyValues();

One of the cool things about Identities is that it is possible to ask
for an Objects Identity even before it is stored!
(If the Object does not have properly defined primary key values they
will be computed for you, if <autoincrement> is set to true for the
respective attribute.)

I don't believe that it's necessary to change the existing API, as your
requirements (as I understand them) can be fulfilled with the existing
mechanisms.

Nevertheless: all feedback and feature requests are welcome!

cheers,

Thomas

Re: [OJB-developers] Problem with version 0.7.250

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

Hi again David,



David Forslund wrote:
> 
> I'm having trouble with version 0.7.250 that I don't fully understand.
> 
> I have to tables: Identity and Trait.
> 
> Identity contains a collection of Traits (foreign key: id in
> Identity);
> 
> Trait can optionally contain a collection of Traits (foreign key:
> parent_id in Trait).
> 
> This all works with 0.5.180, but I have to manually load the Traits
> associated with an Identity
> when requested.
> 
> In 0.7.250, it seems to automatically load the dependent data when I
> use <inverse_fk_descriptor_ids>.
> 

If I get you right you had no <descriptor_ids> set in the 0.5.180
version?
You loaded the Traits manually?
What about the "recursive" association from a Trait to it's n child
Traits?
Did you have a collection descriptor with a <descriptor_ids> setting
under 0.5.180?

> It loads the data and everything seems fine.  When I try to read the
> data in however, it seems to
> get caught in a tight loop and doesn't complete the request.  I don't
> understand why, other than
> that the Traits are recursive (linked to other Traits).   I can't tell
> why this is happening.
> 

Recursive associations are a tested feature and apart from the syntax
change from <descriptor_ids> to <inverse_fk_descriptor_ids> I don't
remember any changes on stuff related to this.

Please send me your classes Identity and Trait, The code that produces
the error, a full stactrace if possible, your repository.xml and the
tables DDL to get a clearer sight what's going wrong.

-- Thomas

 

> Any ideas or things I should look for?
> 
> Thanks,
> 
> David W. Forslund                               dw...@la...
> Computer and Computational
> Sciences             http://www.acl.lanl.gov/~dwf
> Los Alamos National Laboratory          Los Alamos, NM
> 87545
> 505-663-5218                                    FAX: 505-663-5225

[OJB-developers] Problem with version 0.7.250

[David F. <dw...@la...>]

I'm having trouble with version 0.7.250 that I don't fully understand.

I have to tables: Identity and Trait.

Identity contains a collection of Traits (foreign key: id in Identity);

Trait can optionally contain a collection of Traits (foreign key: parent_id 
in Trait).

This all works with 0.5.180, but I have to manually load the Traits 
associated with an Identity
when requested.

In 0.7.250, it seems to automatically load the dependent data when I use 
<inverse_fk_descriptor_ids>.

It loads the data and everything seems fine.  When I try to read the data 
in however, it seems to
get caught in a tight loop and doesn't complete the request.  I don't 
understand why, other than
that the Traits are recursive (linked to other Traits).   I can't tell why 
this is happening.

Any ideas or things I should look for?

Thanks,


David W. Forslund                               dw...@la...
Computer and Computational Sciences             http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory          Los Alamos, NM 87545
505-663-5218                                    FAX: 505-663-5225

[OJB-developers] Re: Problem with cascade delete and null references

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

Thanks Rainer,

I will add this to my ever growing todo list...

-- Thomas

"Bischof, Rainer" wrote:
> 
> Thomas,
> 
> I guess I found the next bug:
> In PersistenceBrokerImpl.deleteReferences there is
> 
> [...]
>   try
>   {
>     Object r = rds.getPersistentField().get(obj);
>     delete(r);
>   }
>   catch (Exception ex)
>   {
>     ex.printStackTrace();
>   }
> [...]
> 
> If cascade delete is activated and the reference is null this leads to a
> NullPointerException in the delete method. This exception is ( once again
> ;-) ) caught and silently ignored.
> 
> Thanks
> Rainer
> 
> Rainer Bischof
> EDS - Electronic Data Systems
> European Automotive Solution Center - Distributed Solutions
> Email: rai...@ed... <mailto:rai...@ed...>

[OJB-developers] Problem with cascade delete and null references

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

Thomas,

I guess I found the next bug:
In PersistenceBrokerImpl.deleteReferences there is

[...]
  try
  {
    Object r = rds.getPersistentField().get(obj);
    delete(r);
  }
  catch (Exception ex)
  {
    ex.printStackTrace();
  }
[...]


If cascade delete is activated and the reference is null this leads to a
NullPointerException in the delete method. This exception is ( once again
;-) ) caught and silently ignored.

Thanks
Rainer

Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions
Email: rai...@ed... <mailto:rai...@ed...> 

Re: [OJB-developers] problem with schema

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

Hi again Bertrand,

You are right, this is a bug. It's No. 26 on the ever growing todo list
!
Thanks for your patience with OJB !

-- Thomas


ber...@wa... wrote:
> 
> Hi,
> 
> I have some strange behavior when I try to use schema name for my tables
> If I have something like this in my repository
> 
> <ClassDescriptor id="1">
>    <class.name>mmcalendar.object.ActionObject</class.name>
>    <schema.name>MMLCDTA</schema.name>
>    <table.name>MKMPAC</table.name>
>    <rowReader>mmcalendar.object.ActionObjectRowReader</rowReader>
>    <FieldDescriptor id="1">
>      <field.name>_keyOpgn</field.name>
>      <column.name>OPGNAC</column.name>
>      <jdbc_type>INTEGER</jdbc_type>
>      <PrimaryKey>true</PrimaryKey>
>    </FieldDescriptor>
> 
> I got the following sql
> 
> select mkmpac.opgnac from mmlcdta.mkmpac
> 
> which is not valid with DB2
> I should have
> 
> select mmlcdta.mkmpac.opgnac from mmlcdta.mkmpac
>              ^^^^
> so maybe getListOfColumns(ClassDescriptor mif, boolean useFullNames) in
> SqlGenerator should also add the schema when requestiong fullnames.
> 
> Now when if I tried to solve my problem with a new schema
> 
> <ClassDescriptor id="1">
>    <class.name>mmcalendar.object.ActionObject</class.name>
> <!--   <schema.name>MMLCDTA</schema.name> ->
>    <table.name>MMLCDTA.MKMPAC</table.name>
>    <rowReader>mmcalendar.object.ActionObjectRowReader</rowReader>
>    <FieldDescriptor id="1">
>      <field.name>_keyOpgn</field.name>
>      <column.name>OPGNAC</column.name>
>      <jdbc_type>INTEGER</jdbc_type>
>      <PrimaryKey>true</PrimaryKey>
>    </FieldDescriptor>
> 
> I received the following SQL
> select mmlcdta.mkmpac.opgnac from mmlcdta.mmlcdta.mkmpac
> 
> I finally realized that I had another Classdescriptor on the same
> connection that also define a   <schema.name>MMLCDTA</schema.name>
> <ClassDescriptor id="4">
>    <class.name>mmcalendar.object.EmployeeObject</class.name>
>    <schema.name>MMLCDTA</schema.name>
>    <table.name>MKMPGB</table.name>
> 
> the schema is pusched to the connection and so it is used for all tables of
> the same connection (the default one in may case).
> I haven't tested what happens if all tables don't agree on the shcema to
> use.
> 
> So removing all <schema.name> tag and unisng the schema.table notation with
> all my classes solved the problem
> but It does look strange to me.
> 
> Thank you
> 
> Bertrand
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

[OJB-developers] problem with schema

[<ber...@wa...>]

Hi,

I have some strange behavior when I try to use schema name for my tables
If I have something like this in my repository

<ClassDescriptor id="1">
   <class.name>mmcalendar.object.ActionObject</class.name>
   <schema.name>MMLCDTA</schema.name>
   <table.name>MKMPAC</table.name>
   <rowReader>mmcalendar.object.ActionObjectRowReader</rowReader>
   <FieldDescriptor id="1">
     <field.name>_keyOpgn</field.name>
     <column.name>OPGNAC</column.name>
     <jdbc_type>INTEGER</jdbc_type>
     <PrimaryKey>true</PrimaryKey>
   </FieldDescriptor>

I got the following sql

select mkmpac.opgnac from mmlcdta.mkmpac

which is not valid with DB2
I should have

select mmlcdta.mkmpac.opgnac from mmlcdta.mkmpac
             ^^^^
so maybe getListOfColumns(ClassDescriptor mif, boolean useFullNames) in
SqlGenerator should also add the schema when requestiong fullnames.

Now when if I tried to solve my problem with a new schema

<ClassDescriptor id="1">
   <class.name>mmcalendar.object.ActionObject</class.name>
<!--   <schema.name>MMLCDTA</schema.name> ->
   <table.name>MMLCDTA.MKMPAC</table.name>
   <rowReader>mmcalendar.object.ActionObjectRowReader</rowReader>
   <FieldDescriptor id="1">
     <field.name>_keyOpgn</field.name>
     <column.name>OPGNAC</column.name>
     <jdbc_type>INTEGER</jdbc_type>
     <PrimaryKey>true</PrimaryKey>
   </FieldDescriptor>

I received the following SQL
select mmlcdta.mkmpac.opgnac from mmlcdta.mmlcdta.mkmpac

I finally realized that I had another Classdescriptor on the same
connection that also define a   <schema.name>MMLCDTA</schema.name>
<ClassDescriptor id="4">
   <class.name>mmcalendar.object.EmployeeObject</class.name>
   <schema.name>MMLCDTA</schema.name>
   <table.name>MKMPGB</table.name>

the schema is pusched to the connection and so it is used for all tables of
the same connection (the default one in may case).
I haven't tested what happens if all tables don't agree on the shcema to
use.

So removing all <schema.name> tag and unisng the schema.table notation with
all my classes solved the problem
but It does look strange to me.

Thank you

Bertrand

Re: [OJB-developers] new release: OJB 0.7.250

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

hi thomas,

thanks for the new release.
regarding to-do 100 and 106, i think 100 is already fixed in 7.250. 106 is
in one of my zip i sent recently.
btw do you integrate 106 and DISTINCT in the current release, or shall i do
it and send the patches, or do we need to rethink those issues ?

jakob

ps: i will slowdown a little...

----- Original Message -----
From: "Mahler Thomas" <tho...@it...>
To: <obj...@li...>
Sent: Sunday, December 09, 2001 4:19 PM
Subject: [OJB-developers] new release: OJB 0.7.250


>
> Hi all,
>
> I just published a new release on SF.
> The new release brings some important new features:
>
> - Automatic assignment of foreign keys
> - Improved Query interface: NOT, IN, BETWEEN, iSNULL ... (thanks to Jakob)
> - Path Epressions: let SqlGenerator build joins (also thanks to Jakob)
> - Cache synchronisation for PersistenceBrokerServer clusters
>
> Jakob sends in so many good code that I have problems in getting it all
> integrated fast enough...
> Thanks a lot for your contributions!
>
> attached you'll find the current status update.
>
> enJoy,
>
> Thomas
>
>

Re: [OJB-developers] Handling Exception

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

Hi Bertrand,

you are right, this is really annoying.
There is a prio 1 task on the todo list (No. 25) covering your request.
Now that the most important features for release 1.0 are implemented I
don't have any excuses not to start this task!
(of cause it's more fun to implement new features than to fix bugs....)

I hope work on this soon ;-)

cheers,

Thomas

ber...@wa... wrote:
> 
> Hi,
> 
> I have a problem with the way Obj handles exceptions.
> 
> For example,
> when I do a getIteratorByQuery(),  if something goes wrong with my database
> during a prepare statement
> the exception will be caught in StatementForClass::getPreparedStatement()
> that will print a trace on the console but I will
> receive a perfectly correct  Iterator that will return no element.
> In the program itself there is no way to tell the difference between such
> an error condition and a query that will return no element, if the program
> runs stand alone, the only way is to redirect standard output and go and
> look for error message.
> 
> I think it would be better for StatementForClass::getPreparedStatement to
> throw a new PersistenceBrokerException. That way the program could decide
> how to handle the error.
> Of course all the methods called along the chain should be modified so that
> they declare that they throw a PersistenceBrokerException and don't hide
> the exception themself.
> This should also make thinks easier for unit testing.
> 
> I modified the different methods for getIteratorByQuery() as an example.I
> have added a //!! comment in the different places where I made a change.
> 
> Of course many more methods do just the same as
> StatementForClass::getPreparedStatement() and many more changes will be
> needed.
> Because PersistenceBrokerException extends RuntimeException adding the
> throw clause isn't required but is it really a good idea to have all
> exception behaving as runtime exceptions. In the code there seems to be
> Methods that declare to throw the exception other that don't, sometime very
> similar methods like
> getIteratorByQuery() and getIteratorFromQuery().
> 
> If you think the change is worth it I could give you some help.
> 
> Bertrand
> 
> PersistenceBrokerImpl:
>     public Iterator getIteratorByQuery(Query query) throws
> PersistenceBrokerException
>     {
>         Class itemClass = query.getSearchClass();
>         ClassDescriptor cld =
> m_DescriptorRepository.getDescriptorFor(itemClass);
>         return getIteratorFromQuery(query, cld);
>     }
> 
>     private Iterator getIteratorFromQuery(Query query, ClassDescriptor mif)
> //!!
>     throws PersistenceBrokerException
>     {
> //!!
> /*        try
>         {
>             RsIterator iter = null;
>             iter = new RsIterator(query, mif, this);
>             return iter;
>         }
>         catch (Exception ex)
>         {
>             System.out.println("get iterator from query " + ex.getMessage
> ());
>             ex.printStackTrace();
>         }
>         return null;
> */
>             RsIterator iter = null;
>             iter = new RsIterator(query, mif, this);
>             return iter;
> 
>     }
> 
> RsIterator:
>     public RsIterator(Query query, ClassDescriptor mif,
> PersistenceBrokerImpl broker)
> //!!
>     throws PersistenceBrokerException
>     {
>         if (_debug)
>         {
>             System.out.println("RsIterator(" + query + ", " + mif + ")");
>         }
>         m_rs = new JdbcAccess(broker).executeQuery(query, mif);
>         m_broker = broker;
>         m_mif = mif;
>         itemProxyClass = mif.getProxyClass();
>     }
> 
> JdbcAccess
>     ResultSet executeQuery(Query query, ClassDescriptor mif)
> //!!
>     throws PersistenceBrokerException
>     {
>         if (_debug)
>         {
>             System.out.println("executeQuery: " + query);
>         }
>         try
>         {
>             // if query has criteria, use them in where clause
>             if (query.getCriteria() != null && !query.getCriteria().isEmpty
> ())
>             {
> 
>                 String sql = SqlGenerator.getInstance
> ().getPreparedSelectStatement(query, mif);
>                 PreparedStatement stmt = broker.getStatementManager
> ().getPreparedStatement(mif, sql);
>                 broker.getStatementManager().bindStatement(stmt,
> query.getCriteria(), mif, 1);
>                 ResultSet rs = stmt.executeQuery();
>                 // as we return the resultset for further operations, we
> cannot release the statement yet.
>                 // that has to be done by the JdbcAccess-clients (i.e.
> RsIterator, ProxyRsIterator and PkEnumeration.)
>                 return rs;
> 
>             }
>             // if query has no criteria, perform select * from table
>             else
>             {
>                 Statement stmt = broker.getStatementManager
> ().getGenericStatement(mif);
>                 String sql = SqlGenerator.getInstance
> ().getSelectStatementDep(query, mif);
>                 ResultSet rs = stmt.executeQuery(sql);
>                 return rs;
>             }
>         }
>         catch (Exception ex)
>         {
> //!!
>             System.out.println("execute query " + ex.getMessage());
> //            ex.printStackTrace();
> //            return null;
>             throw new PersistenceBrokerException( ex) ;
> 
>         }
>     }
> 
> StatementManager
>   public PreparedStatement getPreparedStatement(ClassDescriptor cds, String
> sql)
>   throws PersistenceBrokerException
>   {
>     return getStatementsForClass(cds).getPreparedStmt(sql);
>   }
> 
> StatementForClass
> public PreparedStatement getPreparedStmt(String sql)
> //!!!
> throws PersistenceBrokerException
> {
>         PreparedStatement stmt = null;
>         try
>         {
>             stmt = prepareStatement(sql);
>         }
>         catch (java.sql.SQLException ex)
>         {
> //!!!
>             System.err.println(ex.getMessage());
>             ex.printStackTrace();
>             throw new PersistenceBrokerException( ex) ;
>         }
>         return stmt;
> }
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] "constant" values in where clause

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

Hi Matt,

> Matt Goodall wrote:
> 
> Hi,
> 
> I'm still trying to understand what's actually possible with OJB ...
> 
> If I have a table defined something like this:
> 
>     type varchar(xxx)
>     short_name varchar(yyy)
>     long_name varchar(zzz)
> 
> which might hold the following:
> 
>     "vehicle", "car", "small thing which can't seem to hold more that
> one person at a time"
>     "vehicle", "train", "long thing which is always late"
>     "fruit", "apple", "green or red round thing"
>     "fruit", "mango", "yum, yum"
>     "fruit", "banana", "yellow, long and bendy. great with custard"
>     ... etc, I'm sure you get the idea by now ;)
>

When I get you right you want to map different Java classes (Vehicle,
Fruit) onto one table.
The column "type" is used as a type identifier.
This is a scenario is described in tutorial3 in section "mapping
inheritance hierachies" in the subsection "mapping all classes on the
same table".

By default OJB expects a full qualified classname in the column "type".
If this is not viable for your, you can implement a RowReader with a
special implementation of the method selectClassDescriptor(...). This is
needed to map your names "vehicle" and "fruit" to real classnames like
"my.own.com.Vehicle" and "my.own.com.Fruit".
 
> Can I tell OJB that I have a class called Fruit with public name and
> description properties and ask OJB for all Fruit (for example) without
> having to qualify that type='fruit' i.e. supply no Criteria to the
> query and only get a list of fruit back?
> 

// select all fruits:
Query q = QueryFactory.newQuery(Fruit.class, null);

HTH,

Thomas

> Thanks, Matt
> ---
> Matt Goodall
> Analyst Programmer, Strategic Systems Solutions
> e: mat...@ss..., t: +44 113 3892645
>

[OJB-developers] <fk_descriptor_ids> syntax

[<ber...@wa...>]

Hello,

When I try to use  <fk_descriptor_ids>1, 4</fk_descriptor_ids>, I receive
an error message.

This is correct with respect to the doc
1.   The tag <fk_descriptor_ids> contains a list of ids of those
descriptors describing the foreignkey fields. In this case it only contains
the id 4. The FieldDescriptor with the id 4 describes the foreignkey
attribute productGroupId. Multiple foreignkey attributes may be separated
by commas.

but in the code I have
                case 23:
                    {
                        if (_debug)
                        {
                            System.out.println("     fk_descriptor_ids: " +
m_CurrentString);
                        }
                        Vector v = new Vector();
                        StringTokenizer st = new
StringTokenizer(m_CurrentString, " ");

I replace , with spaces and it now works.

One of the two should be corrected.

Thank you

Bertrand

Re: [OJB-developers] OJB DISTINCT

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

hi dirk,

there's a setDistinct(boolean) in QueryByCriteria. The third attribute is
only for convenience.

jakob

----- Original Message -----
From: "Dirk Olmes" <di...@xa...>
To: "Jakob Braeuchi" <jbr...@ho...>
Cc: "Objectbridge Developers List (E-mail)"
<obj...@li...>
Sent: Monday, December 10, 2001 12:56 PM
Subject: Re: [OJB-developers] OJB DISTINCT


> > the attached zip enables setting DISTINCT in sql-queries.
> > there are new constructors in QueryFactory with an additional boolean
> > parameter 'distinct'.
> >
> > the following snippet shows a sample (one person has many accounts and
> > many
> > telephones) and the generated sql.
> > the sql also shows, that multiple joins work:
> >
> > Query query;
> > Criteria crit;
> >
> > System.out.println("\nread all person with konti.saldo > 200 and tel
> > like
> > 031%");
> > crit = new Criteria();
> > crit.addGreaterThan("konti.saldo",new Integer(100));
> > crit.addLike("telefone.nummer","031%");
> > query = new QueryByCriteria(Person.class, crit,true);         // true ->
> > DISTINCT
>
> Not knowing much of the internals of OJB (I dug into the source once but
> this is long time gone) I find the third argument to the constructor
> awkward API.
>
> Wouldn't it be clearer API to be able to write:
>
> crit = new Criteria();
> crit.addGreaterThan("konti.saldo",new Integer(100));
> crit.addLike("telefone.nummer","031%");4
> crit.setUsesDistinct(true);
> query = new QueryByCriteria(Person.class, crit);
>
> Just my thoughts,
>
> -dirk
>
>

[OJB-developers] Handling Exception

[<ber...@wa...>]

Hi,

I have a problem with the way Obj handles exceptions.

For example,
when I do a getIteratorByQuery(),  if something goes wrong with my database
during a prepare statement
the exception will be caught in StatementForClass::getPreparedStatement()
that will print a trace on the console but I will
receive a perfectly correct  Iterator that will return no element.
In the program itself there is no way to tell the difference between such
an error condition and a query that will return no element, if the program
runs stand alone, the only way is to redirect standard output and go and
look for error message.

I think it would be better for StatementForClass::getPreparedStatement to
throw a new PersistenceBrokerException. That way the program could decide
how to handle the error.
Of course all the methods called along the chain should be modified so that
they declare that they throw a PersistenceBrokerException and don't hide
the exception themself.
This should also make thinks easier for unit testing.

I modified the different methods for getIteratorByQuery() as an example.I
have added a //!! comment in the different places where I made a change.

Of course many more methods do just the same as
StatementForClass::getPreparedStatement() and many more changes will be
needed.
Because PersistenceBrokerException extends RuntimeException adding the
throw clause isn't required but is it really a good idea to have all
exception behaving as runtime exceptions. In the code there seems to be
Methods that declare to throw the exception other that don't, sometime very
similar methods like
getIteratorByQuery() and getIteratorFromQuery().

If you think the change is worth it I could give you some help.

Bertrand

PersistenceBrokerImpl:
    public Iterator getIteratorByQuery(Query query) throws
PersistenceBrokerException
    {
        Class itemClass = query.getSearchClass();
        ClassDescriptor cld =
m_DescriptorRepository.getDescriptorFor(itemClass);
        return getIteratorFromQuery(query, cld);
    }


    private Iterator getIteratorFromQuery(Query query, ClassDescriptor mif)
//!!
    throws PersistenceBrokerException
    {
//!!
/*        try
        {
            RsIterator iter = null;
            iter = new RsIterator(query, mif, this);
            return iter;
        }
        catch (Exception ex)
        {
            System.out.println("get iterator from query " + ex.getMessage
());
            ex.printStackTrace();
        }
        return null;
*/
            RsIterator iter = null;
            iter = new RsIterator(query, mif, this);
            return iter;

    }

RsIterator:
    public RsIterator(Query query, ClassDescriptor mif,
PersistenceBrokerImpl broker)
//!!
    throws PersistenceBrokerException
    {
        if (_debug)
        {
            System.out.println("RsIterator(" + query + ", " + mif + ")");
        }
        m_rs = new JdbcAccess(broker).executeQuery(query, mif);
        m_broker = broker;
        m_mif = mif;
        itemProxyClass = mif.getProxyClass();
    }


JdbcAccess
    ResultSet executeQuery(Query query, ClassDescriptor mif)
//!!
    throws PersistenceBrokerException
    {
        if (_debug)
        {
            System.out.println("executeQuery: " + query);
        }
        try
        {
            // if query has criteria, use them in where clause
            if (query.getCriteria() != null && !query.getCriteria().isEmpty
())
            {

                String sql = SqlGenerator.getInstance
().getPreparedSelectStatement(query, mif);
                PreparedStatement stmt = broker.getStatementManager
().getPreparedStatement(mif, sql);
                broker.getStatementManager().bindStatement(stmt,
query.getCriteria(), mif, 1);
                ResultSet rs = stmt.executeQuery();
                // as we return the resultset for further operations, we
cannot release the statement yet.
                // that has to be done by the JdbcAccess-clients (i.e.
RsIterator, ProxyRsIterator and PkEnumeration.)
                return rs;

            }
            // if query has no criteria, perform select * from table
            else
            {
                Statement stmt = broker.getStatementManager
().getGenericStatement(mif);
                String sql = SqlGenerator.getInstance
().getSelectStatementDep(query, mif);
                ResultSet rs = stmt.executeQuery(sql);
                return rs;
            }
        }
        catch (Exception ex)
        {
//!!
            System.out.println("execute query " + ex.getMessage());
//            ex.printStackTrace();
//            return null;
            throw new PersistenceBrokerException( ex) ;

        }
    }


StatementManager
  public PreparedStatement getPreparedStatement(ClassDescriptor cds, String
sql)
  throws PersistenceBrokerException
  {
    return getStatementsForClass(cds).getPreparedStmt(sql);
  }


StatementForClass
public PreparedStatement getPreparedStmt(String sql)
//!!!
throws PersistenceBrokerException
{
        PreparedStatement stmt = null;
        try
        {
            stmt = prepareStatement(sql);
        }
        catch (java.sql.SQLException ex)
        {
//!!!
            System.err.println(ex.getMessage());
            ex.printStackTrace();
            throw new PersistenceBrokerException( ex) ;
        }
        return stmt;
}

[OJB-developers] "constant" values in where clause

[Matt G. <mat...@ss...>]

Hi,

I'm still trying to understand what's actually possible with OJB ...

If I have a table defined something like this:

    type varchar(xxx)
    short_name varchar(yyy)
    long_name varchar(zzz)

which might hold the following:

    "vehicle", "car", "small thing which can't seem to hold more that one
person at a time"
    "vehicle", "train", "long thing which is always late"
    "fruit", "apple", "green or red round thing"
    "fruit", "mango", "yum, yum"
    "fruit", "banana", "yellow, long and bendy. great with custard"
    ... etc, I'm sure you get the idea by now ;)

Can I tell OJB that I have a class called Fruit with public name and
description properties and ask OJB for all Fruit (for example) without
having to qualify that type='fruit' i.e. supply no Criteria to the query and
only get a list of fruit back?

Thanks, Matt
---
Matt Goodall
Analyst Programmer, Strategic Systems Solutions
e: mat...@ss..., t: +44 113 3892645

RE: [OJB-developers] new release: OJB 0.7.250 (fwd)

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

Hi Georg,

Hi,
Just wanted to make sure if I really understand what automatic
assignment
of foreign keys means.
If I have 1:n relationship let's say between ProductGroup and Article,
which means that I have a collection of Articles in the class
ProductGroup. The mapping onto the relational layer implies that I will
have a foreign key attribute in the Article table pointing to the
ProductGroup. Does automatic foreign key assignment mean that I don't
have
to manually set the productGroupId in the Article class and that when I
add an Article to the ProductGroup this field is set automatically?

Exactly!
Please have a look at the JUnit test test.ojb.broker.AutomaticForeignKeys
for a working example.

-- Thomas

Re: [OJB-developers] OJB DISTINCT

[Dirk O. <di...@xa...>]

> the attached zip enables setting DISTINCT in sql-queries.
> there are new constructors in QueryFactory with an additional boolean
> parameter 'distinct'.
>
> the following snippet shows a sample (one person has many accounts and 
> many
> telephones) and the generated sql.
> the sql also shows, that multiple joins work:
>
> Query query;
> Criteria crit;
>
> System.out.println("\nread all person with konti.saldo > 200 and tel 
> like
> 031%");
> crit = new Criteria();
> crit.addGreaterThan("konti.saldo",new Integer(100));
> crit.addLike("telefone.nummer","031%");
> query = new QueryByCriteria(Person.class, crit,true);         // true ->
> DISTINCT

Not knowing much of the internals of OJB (I dug into the source once but 
this is long time gone) I find the third argument to the constructor 
awkward API.

Wouldn't it be clearer API to be able to write:

crit = new Criteria();
crit.addGreaterThan("konti.saldo",new Integer(100));
crit.addLike("telefone.nummer","031%");4
crit.setUsesDistinct(true);
query = new QueryByCriteria(Person.class, crit);

Just my thoughts,

-dirk

Re: [OJB-developers] new release: OJB 0.7.250 (fwd)

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

Hi,
Just wanted to make sure if I really understand what automatic assignment
of foreign keys means.
If I have 1:n relationship let's say between ProductGroup and Article,
which means that I have a collection of Articles in the class
ProductGroup. The mapping onto the relational layer implies that I will
have a foreign key attribute in the Article table pointing to the
ProductGroup. Does automatic foreign key assignment mean that I don't have
to manually set the productGroupId in the Article class and that when I
add an Article to the ProductGroup this field is set automatically?

Tx

Georg

On Mon, 10 Dec 2001, Thomas Mahler wrote:

> Hi all,
>
> I just published a new release on SF.
> The new release brings some important new features:
>
> - Automatic assignment of foreign keys
> - Improved Query interface: NOT, IN, BETWEEN, iSNULL ... (thanks to Jakob)
> - Path Epressions: let SqlGenerator build joins (also thanks to Jakob)
> - Cache synchronisation for PersistenceBrokerServer clusters
>
> Jakob sends in so many good code that I have problems in getting it all
> integrated fast enough...
> Thanks a lot for your contributions!
>
> attached you'll find the current status update.
>
> enJoy,
>
> Thomas
>
> [I'm currently have problems with SENDING emails from my normal email
> accounts. All my mailings to the list during the last days have been 'eaten
> up'...]
>
>
> _________________________________________________________________
> Downloaden Sie MSN Explorer kostenlos unter http://explorer.msn.de/intl.asp
>

[OJB-developers] new release: OJB 0.7.250

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

Hi all,

I just published a new release on SF.
The new release brings some important new features:

- Automatic assignment of foreign keys
- Improved Query interface: NOT, IN, BETWEEN, iSNULL ... (thanks to Jakob)
- Path Epressions: let SqlGenerator build joins (also thanks to Jakob)
- Cache synchronisation for PersistenceBrokerServer clusters

Jakob sends in so many good code that I have problems in getting it all
integrated fast enough...
Thanks a lot for your contributions!

attached you'll find the current status update.

enJoy,

Thomas