objectbridge-developers — public list for developer issues

[OJB-developers] Limit Number Of Objects in Query

[Domagoj J. <do...@la...>]

OK, this is a theoretical question, I didn't used OJB yet so maybe this is 
supported feature but I am not aware of it ?

So I want to know is it possible to limit (aka: Statement.setMaxRows() ) 
the number of returned objects by query.
Or using scrollable ResultSet and getting rows from database and 
materializing objects as they needed would be even better, much better.

AW: [OJB-developers] Let's fix the testsuite!

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

Hi Oleg,

> -----Ursprungliche Nachricht-----
> Von: =D0=ED=E5=FA =CF=EA=E7 [mailto:on...@uk...]
> Gesendet: Mittwoch, 29. Mai 2002 10:42
> An: obj...@so...
> Betreff: Re: [OJB-developers] Let's fix the testsuite!
>=20
>=20
> Hi Thomas,
>=20
> I am afraid I was not clear enough, actually I proposed two=20
> alternatives, and you commented only the first one, see below.
>=20

sorry, I missed that it were two separate suggestions.

> -----Original Message-----
> From: Thomas Mahler <tho...@ho...>
> To: Oleg Nitz <on...@uk...>
> Date: Tue, 28 May 2002 23:05:59 +0200
> Subject: Re: AW: [OJB-developers] Let's fix the testsuite!
>=20
> > > I see. To achieve this we should either=20
>=20
> 1)
> > > remember the original state of the m:n relation=20
> You commented this one, and I agree that it requires locks.
>=20
> > > or=20
>=20
> 2)
> > > to read the set of all indirection instances from the=20
> > > database in storeMtoNImplementor(), then compare them against=20
> > > the current set of indirection instances in memory,=20
> > > then insert/delete the two differences of two sets.=20
> > > Then there is no need in multiple database lookups.
> This approach is almost as simple as yours.
> First we execute=20
> SELECT fk_for_items FROM indirect_table WHERE fk_for_this=3D?
> and put then into the set1
> The identities for the current m:n collection we put into set2
> Then we calculate "set1 minus set2" and DELETE  these records
> Then we calculate "set2 minus set1" and INSERT  these records
>=20

I agree, this is also quite simple and will eliminate superfluous =
DELETEs !
This is even better than my idea.

cheers,

Thomas

> > A much simpler aproach:
> > before inserting entries for a given relation in=20
> storeMtoNImplementor(),=20
> > just delete all existing entries.
> > This way we
> > - can avoid exception caused by failing inserts,
> > - won't need to track object state to detect removed entries.
> > Overhead should be rather small we'll need to execute only=20
> one DELETE=20
> > statement.
> You are right, we need to execute only one DELETE statement,=20
> but every time we will execute 1 DELETE and many INSERTs,=20
> even if nothing changed.
> With my 2nd approach we will execute 1 SELECT and the number=20
> of DELETEs and INSERTs that is really necessary, i.e. zero if=20
> nothing changed.
> And in general this approach seems more careful :)
> Do you agree?
>=20
> Oleg
>=20
> _______________________________________________________________
>=20
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- =
http://devcon.sprintpcs.com/adp/index.cfm
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20

Re: [OJB-developers] Let's fix the testsuite!

[ïÌÅÇ î. <on...@uk...>]

Hi Thomas,

I am afraid I was not clear enough, actually I proposed two alternatives, and you commented only the first one, see below.

-----Original Message-----
From: Thomas Mahler <tho...@ho...>
To: Oleg Nitz <on...@uk...>
Date: Tue, 28 May 2002 23:05:59 +0200
Subject: Re: AW: [OJB-developers] Let's fix the testsuite!

> > I see. To achieve this we should either 

1)
> > remember the original state of the m:n relation 
You commented this one, and I agree that it requires locks.

> > or 

2)
> > to read the set of all indirection instances from the 
> > database in storeMtoNImplementor(), then compare them against 
> > the current set of indirection instances in memory, 
> > then insert/delete the two differences of two sets. 
> > Then there is no need in multiple database lookups.
This approach is almost as simple as yours.
First we execute 
SELECT fk_for_items FROM indirect_table WHERE fk_for_this=?
and put then into the set1
The identities for the current m:n collection we put into set2
Then we calculate "set1 minus set2" and DELETE  these records
Then we calculate "set2 minus set1" and INSERT  these records

> A much simpler aproach:
> before inserting entries for a given relation in storeMtoNImplementor(), 
> just delete all existing entries.
> This way we
> - can avoid exception caused by failing inserts,
> - won't need to track object state to detect removed entries.
> Overhead should be rather small we'll need to execute only one DELETE 
> statement.
You are right, we need to execute only one DELETE statement, but every time we will execute 1 DELETE and many INSERTs, even if nothing changed.
With my 2nd approach we will execute 1 SELECT and the number of DELETEs and INSERTs that is really necessary, i.e. zero if nothing changed.
And in general this approach seems more careful :)
Do you agree?

Oleg

Re: AW: [OJB-developers] Let's fix the testsuite!

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

Hi again,

Oleg Nitz wrote:

> Hi Thomas,
> 
> On Tuesday 28 May 2002 10:14, Mahler Thomas wrote:
> 
>>>But maybe there are some problems with this?
>>>
>>I don't see any. in storeMtoNImplementor() we should check if an entry
>>already exists. If so do nothing, else insert a new entry.
>>
> No you mean repetitive database lookups? 


yes, that's ugly, that's why I implemented it the "easy" way initially...


> 
>>>BTW I wonder if the current algorithm works when some link
>>>between Persons
>>>and Projects is removed.
>>>
>>Currently there is no support to remove m:n entries automatically. They
>>have to be deleted manually.
>>
> I see. To achieve this we should either remember the original state of the 
> m:n relation or to read the set of all indirection instances from the 
> database in storeMtoNImplementor(), then compare them against the current set 
> of indirection instances in memory, then insert/delete the two differences of 
> two sets. Then there is no need in multiple database lookups.
> 


This sounds good, but we must be very careful wrt. to concurrent 
transaction.

The basic design of a broker is to be an stateless service. Of course a 
broker has a transaction state, but is does not know anything about the 
state of persistent instances. Once we start to store object state 
information within the broker we'll need a lot more thinking.
(concurrent transactions, broker pooling mechanism, cache 
synchronization accross JVM, setc.)

A much simpler aproach:
before inserting entries for a given relation in storeMtoNImplementor(), 
just delete all existing entries.
This way we
- can avoid exception caused by failing inserts,
- won't need to track object state to detect removed entries.
Overhead should be rather small we'll need to execute only one DELETE 
statement.


what do you think?


Thomas




> 
>>I'll have a look at 4. and 5. then!
>>
> Okay! :)
> 
> Thanks,
>  Oleg
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

Re: AW: [OJB-developers] Let's fix the testsuite!

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

Hi Thomas,

On Tuesday 28 May 2002 10:14, Mahler Thomas wrote:
> > But maybe there are some problems with this?
>
> I don't see any. in storeMtoNImplementor() we should check if an entry
> already exists. If so do nothing, else insert a new entry.
No you mean repetitive database lookups? 

> > BTW I wonder if the current algorithm works when some link
> > between Persons
> > and Projects is removed.
>
> Currently there is no support to remove m:n entries automatically. They
> have to be deleted manually.
I see. To achieve this we should either remember the original state of the 
m:n relation or to read the set of all indirection instances from the 
database in storeMtoNImplementor(), then compare them against the current set 
of indirection instances in memory, then insert/delete the two differences of 
two sets. Then there is no need in multiple database lookups.

> I'll have a look at 4. and 5. then!
Okay! :)

Thanks,
 Oleg

Re: [OJB-developers] Let's fix the testsuite!

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

Hi Jakob,

On Tuesday 28 May 2002 08:59, Jakob Braeuchi wrote:
> hi oleg,
>
> i can only comment 3.)
>
> > 3) Several errors "Object has been modified by someone else"
> > I am not yet familiar with locking stuff, so could somebody look into
>
> this?
>
> in this test an OptimisticLockException has to be thrown if everything is
> ok, but to avoid confusion it probably should not show up in the console.
Okay, but note that JUnit reports 1 failure for test.ojb.broker.AllTests.
Probably I just haven't noticed it among all those planned exceptions :)

Thanks,
 Oleg

RE: [OJB-developers] non-decomposed m:n-mappings update problem

[Hoang, H. <Hai...@co...>]

1.	There is no exceptions
2.	Based on the generated sql statements, I only see the insert
statements even though I was trying to remove a Permission from a Role.

 

For example I've RoleId = 37, PermissionId = 1, 3, 6.  Now, I want to remove
PermissionId=1 from a Role, What I want to see is

 

1.       DELETE htg_role_permission where role_id = 37

2.       INSERT INTO htg_role_permission (role_id,permission_id) VALUES
(37,3)

3.       INSERT INTO htg_role_permission (role_id,permission_id) VALUES
(37,6)

 

Is this a bug? Is anyone out there using this feature successfully?

 

 

 

 

[ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: SELECT
htg_role.role_id,htg_role.role_name,htg_rol

e.description,htg_role.parent_id FROM htg_role,htg_role_permission WHERE
(permission_id= ? )  AND ht

g_role_permission.role_id=htg_role.role_id ORDER BY htg_role.role_name

[ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: INSERT INTO
htg_role_permission (role_id,permissio

n_id) VALUES (37,3)

[ojb.broker.accesslayer.SqlGenerator] DEBUG: SQL: INSERT INTO
htg_role_permission (role_id,permissio

n_id) VALUES (37,6)

 

 

 

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...] 
Sent: Tuesday, May 28, 2002 12:09 PM
To: Hoang, Hai; 'ojb-developer'
Subject: Re: [OJB-developers] non-decomposed m:n-mappings update problem

 

hi,

 

1./2. so you have no exceptions at all ?

3. to enable SqlGenerator logging use

 

# Loger for SqlGenerator, useful for debugging generation of SQL
ojb.broker.accesslayer.SqlGenerator.LogLevel=DEBUG

in OJB.properties.

 

4. have you tried the latest cvs

 

jakob

----- Original Message ----- 

From: Hoang, Hai <mailto:Hai...@co...>  

To: 'Jakob <mailto:jbr...@ho...>  Braeuchi' ; 'ojb-developer'
<mailto:obj...@li...>  

Sent: Tuesday, May 28, 2002 6:34 PM

Subject: RE: [OJB-developers] non-decomposed m:n-mappings update problem

 

1.      It doesn't work when I try to remove a Permission to a Role

2.      It doesn't work when I tried to update a ParentId field on the Role.
ParentId has a recursive relationship with the Id field.

3.      I don't know where to find the generated sql-statement.  Can anyone
please show me

4.      I am using the latest build (8.4)

5.      I've tested both APIs but they both not working.

 

 

-----Original Message-----
From: Hoang, Hai 
Sent: Tuesday, May 28, 2002 11:05 AM
To: 'Jakob Braeuchi'; 'ojb-developer'
Subject: RE: [OJB-developers] non-decomposed m:n-mappings update problem

 

 

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...] 
Sent: Tuesday, May 28, 2002 10:24 AM
To: Hoang, Hai; obj...@li...
Subject: Re: [OJB-developers] non-decomposed m:n-mappings update problem

 

hi,

 

what do you mean by 'does not work', was there an exception ? what version
of ojb do you use ?

what did you try to do (insert or update) ? could you please provide the
generated sql-statements ?

 

jakob

 

Re: [OJB-developers] non-decomposed m:n-mappings update problem

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

hi,

1./2. so you have no exceptions at all ?
3. to enable SqlGenerator logging use

# Loger for SqlGenerator, useful for debugging generation of SQL
ojb.broker.accesslayer.SqlGenerator.LogLevel=3DDEBUG

in OJB.properties.

4. have you tried the latest cvs

jakob
  ----- Original Message -----=20
  From: Hoang, Hai=20
  To: 'Jakob Braeuchi' ; 'ojb-developer'=20
  Sent: Tuesday, May 28, 2002 6:34 PM
  Subject: RE: [OJB-developers] non-decomposed m:n-mappings update =
problem


  1.      It doesn't work when I try to remove a Permission to a Role

  2.      It doesn't work when I tried to update a ParentId field on the =
Role.  ParentId has a recursive relationship with the Id field.

  3.      I don't know where to find the generated sql-statement.  Can =
anyone please show me

  4.      I am using the latest build (8.4)

  5.      I've tested both APIs but they both not working.





  -----Original Message-----
  From: Hoang, Hai=20
  Sent: Tuesday, May 28, 2002 11:05 AM
  To: 'Jakob Braeuchi'; 'ojb-developer'
  Subject: RE: [OJB-developers] non-decomposed m:n-mappings update =
problem





  -----Original Message-----
  From: Jakob Braeuchi [mailto:jbr...@ho...]=20
  Sent: Tuesday, May 28, 2002 10:24 AM
  To: Hoang, Hai; obj...@li...
  Subject: Re: [OJB-developers] non-decomposed m:n-mappings update =
problem



  hi,



  what do you mean by 'does not work', was there an exception ? what =
version of ojb do you use ?

  what did you try to do (insert or update) ? could you please provide =
the generated sql-statements ?



  jakob

RE: [OJB-developers] non-decomposed m:n-mappings update problem

[Hoang, H. <Hai...@co...>]

1.      It doesn't work when I try to remove a Permission to a Role

2.      It doesn't work when I tried to update a ParentId field on the Role.
ParentId has a recursive relationship with the Id field.

3.      I don't know where to find the generated sql-statement.  Can anyone
please show me

4.      I am using the latest build (8.4)

5.      I've tested both APIs but they both not working.

 

 

-----Original Message-----
From: Hoang, Hai 
Sent: Tuesday, May 28, 2002 11:05 AM
To: 'Jakob Braeuchi'; 'ojb-developer'
Subject: RE: [OJB-developers] non-decomposed m:n-mappings update problem

 

 

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...] 
Sent: Tuesday, May 28, 2002 10:24 AM
To: Hoang, Hai; obj...@li...
Subject: Re: [OJB-developers] non-decomposed m:n-mappings update problem

 

hi,

 

what do you mean by 'does not work', was there an exception ? what version
of ojb do you use ?

what did you try to do (insert or update) ? could you please provide the
generated sql-statements ?

 

jakob

 

RE: [OJB-developers] non-decomposed m:n-mappings update problem

[Hoang, H. <Hai...@co...>]

1.	It doesn't work when I try to remove a Permission to a Role
2.	It doesn't work when I tried to update a ParentId field on the Role.
ParentId has a recursive relationship with the Id field.

 

-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...] 
Sent: Tuesday, May 28, 2002 10:24 AM
To: Hoang, Hai; obj...@li...
Subject: Re: [OJB-developers] non-decomposed m:n-mappings update problem

 

hi,

 

what do you mean by 'does not work', was there an exception ? what version
of ojb do you use ?

what did you try to do (insert or update) ? could you please provide the
generated sql-statements ?

 

jakob

----- Original Message ----- 

From: Hoang, Hai <mailto:Hai...@co...>  

To: 'obj...@li...'
<mailto:'obj...@li...'>  

Sent: Tuesday, May 28, 2002 4:40 PM

Subject: [OJB-developers] non-decomposed m:n-mappings update problem

 

I've a many-to-many relationship as shown by the following tables,
repository.xml, and the java files:

 

The problems I encountered:

 

1.Update the Role object to include the permissions collection doesn't work 

2.Update the parentId on the role object doesn't work 

3.What is this tag
<inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids> means? 

----------------------------------------------------------------------------
------------------

HTG_PERMISSION

HTG_ROLE

HTG_ROLE_PERMISSION

----------------------------------------------------------------------------
------------------

And the repository.xml file:

 

   <ClassDescriptor id="1">

      <class.name>com.htg.base.bo.PermissionImpl</class.name>

      <table.name>htg_permission</table.name>

      <FieldDescriptor id="1">

         <field.name>id</field.name>

         <column.name>permission_id</column.name>

         <jdbc_type>BIGINT</jdbc_type>

         <PrimaryKey>true</PrimaryKey>

         <autoincrement>true</autoincrement>

      </FieldDescriptor>

      <FieldDescriptor id="2">

         <field.name>name</field.name>

         <column.name>permission_name</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <FieldDescriptor id="3">

         <field.name>description</field.name>

         <column.name>description</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <CollectionDescriptor id="1">

         <cdfield.name>roles</cdfield.name>

         <items.class>com.htg.base.bo.RoleImpl</items.class>

         <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>

         <indirection_table>htg_role_permission</indirection_table>

 
<fks_pointing_to_this_class>permission_id</fks_pointing_to_this_class>

         <fks_pointing_to_items_class>role_id</fks_pointing_to_items_class>

         <auto.retrieve>true</auto.retrieve>

         <auto.update>false</auto.update>

         <auto.delete>false</auto.delete>

         <orderby sort="ASC">name</orderby>

      </CollectionDescriptor>

   </ClassDescriptor>

 

   <ClassDescriptor id="2">

      <class.name>com.htg.base.bo.RoleImpl</class.name>

      <table.name>htg_role</table.name>

      <FieldDescriptor id="1">

         <field.name>id</field.name>

         <column.name>role_id</column.name>

         <jdbc_type>BIGINT</jdbc_type>

         <PrimaryKey>true</PrimaryKey>

         <autoincrement>true</autoincrement>

      </FieldDescriptor>

      <FieldDescriptor id="2">

         <field.name>name</field.name>

         <column.name>role_name</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <FieldDescriptor id="3">

         <field.name>description</field.name>

         <column.name>description</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <FieldDescriptor id="4">

         <field.name>parentId</field.name>

         <column.name>parent_id</column.name>

         <jdbc_type>BIGINT</jdbc_type>

      </FieldDescriptor>

      <CollectionDescriptor id="1">

         <cdfield.name>permissions</cdfield.name>

         <items.class>com.htg.base.bo.PermissionImpl</items.class>

         <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>

         <indirection_table>htg_role_permission</indirection_table>

         <fks_pointing_to_this_class>role_id</fks_pointing_to_this_class>

 
<fks_pointing_to_items_class>permission_id</fks_pointing_to_items_class>

         <auto.retrieve>true</auto.retrieve>

         <auto.update>true</auto.update>

         <auto.delete>false</auto.delete>

         <orderby sort="ASC">name</orderby>

      </CollectionDescriptor>

   </ClassDescriptor>

 

----------------------------------------------------------------------------
------------------

public class PermissionImpl implements Permission, Serializable 

{

 

            private Collection roles;

            

            public PermissionImpl()

            {}

            

            public PermissionImpl(Long id, String name, String description)

            {

                        this.id = id;

                        this.name = name;

                        this.description = description;

            }

 

...

 

    public Collection getRoles()

    {

        return roles;

    }

 

    public void setRoles(Collection roles)

    {

        this.roles = roles;

    }

}

 

----------------------------------------------------------------------------
------------------

public class RoleImpl implements Role, Serializable

{

 

            private Long parentId;

            private Collection permissions;

 

            public RoleImpl() 

            {}

            

            public RoleImpl(Long id, String name, String description, Long
parentId) 

            {

                        this.id = id;

                        this.name = name;

                        this.description = description;

                        this.parentId = parentId;

            }

            

...

            /**

             * @see Role#setParentId(Long)

             */

            public void setParentId(Long Id)

            {

                        this.parentId = id;

            }

            /**

             * @see Role#getParentId()

             */

            public Long getParentId()

            {

                        return parentId;

            }

            

            /**

             * @see Role#getPermissions()

             */

            public Collection getPermissions()

            {

                        return permissions;

            }

            

            /**

             * @see Role#setPermissions(Collection)

             */

            public void setPermissions(Collection permissions)

            {

                        this.permissions = permissions;

            }

}           

----------------------------------------------------------------------------
------------------

 

Re: [OJB-developers] non-decomposed m:n-mappings update problem

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

hi,

what do you mean by 'does not work', was there an exception ? what =
version of ojb do you use ?
what did you try to do (insert or update) ? could you please provide the =
generated sql-statements ?

jakob
  ----- Original Message -----=20
  From: Hoang, Hai=20
  To: 'obj...@li...'=20
  Sent: Tuesday, May 28, 2002 4:40 PM
  Subject: [OJB-developers] non-decomposed m:n-mappings update problem


  I've a many-to-many relationship as shown by the following tables, =
repository.xml, and the java files:



  The problems I encountered:



    1.. Update the Role object to include the permissions collection =
doesn't work=20
    2.. Update the parentId on the role object doesn't work=20
    3.. What is this tag =
<inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids> means?=20
  =
-------------------------------------------------------------------------=
---------------------

  HTG_PERMISSION

  HTG_ROLE

  HTG_ROLE_PERMISSION

  =
-------------------------------------------------------------------------=
---------------------

  And the repository.xml file:



     <ClassDescriptor id=3D"1">

        <class.name>com.htg.base.bo.PermissionImpl</class.name>

        <table.name>htg_permission</table.name>

        <FieldDescriptor id=3D"1">

           <field.name>id</field.name>

           <column.name>permission_id</column.name>

           <jdbc_type>BIGINT</jdbc_type>

           <PrimaryKey>true</PrimaryKey>

           <autoincrement>true</autoincrement>

        </FieldDescriptor>

        <FieldDescriptor id=3D"2">

           <field.name>name</field.name>

           <column.name>permission_name</column.name>

           <jdbc_type>VARCHAR</jdbc_type>

        </FieldDescriptor>

        <FieldDescriptor id=3D"3">

           <field.name>description</field.name>

           <column.name>description</column.name>

           <jdbc_type>VARCHAR</jdbc_type>

        </FieldDescriptor>

        <CollectionDescriptor id=3D"1">

           <cdfield.name>roles</cdfield.name>

           <items.class>com.htg.base.bo.RoleImpl</items.class>

           <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>

           <indirection_table>htg_role_permission</indirection_table>

           =
<fks_pointing_to_this_class>permission_id</fks_pointing_to_this_class>

           =
<fks_pointing_to_items_class>role_id</fks_pointing_to_items_class>

           <auto.retrieve>true</auto.retrieve>

           <auto.update>false</auto.update>

           <auto.delete>false</auto.delete>

           <orderby sort=3D"ASC">name</orderby>

        </CollectionDescriptor>

     </ClassDescriptor>



     <ClassDescriptor id=3D"2">

        <class.name>com.htg.base.bo.RoleImpl</class.name>

        <table.name>htg_role</table.name>

        <FieldDescriptor id=3D"1">

           <field.name>id</field.name>

           <column.name>role_id</column.name>

           <jdbc_type>BIGINT</jdbc_type>

           <PrimaryKey>true</PrimaryKey>

           <autoincrement>true</autoincrement>

        </FieldDescriptor>

        <FieldDescriptor id=3D"2">

           <field.name>name</field.name>

           <column.name>role_name</column.name>

           <jdbc_type>VARCHAR</jdbc_type>

        </FieldDescriptor>

        <FieldDescriptor id=3D"3">

           <field.name>description</field.name>

           <column.name>description</column.name>

           <jdbc_type>VARCHAR</jdbc_type>

        </FieldDescriptor>

        <FieldDescriptor id=3D"4">

           <field.name>parentId</field.name>

           <column.name>parent_id</column.name>

           <jdbc_type>BIGINT</jdbc_type>

        </FieldDescriptor>

        <CollectionDescriptor id=3D"1">

           <cdfield.name>permissions</cdfield.name>

           <items.class>com.htg.base.bo.PermissionImpl</items.class>

           <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>

           <indirection_table>htg_role_permission</indirection_table>

           =
<fks_pointing_to_this_class>role_id</fks_pointing_to_this_class>

           =
<fks_pointing_to_items_class>permission_id</fks_pointing_to_items_class>

           <auto.retrieve>true</auto.retrieve>

           <auto.update>true</auto.update>

           <auto.delete>false</auto.delete>

           <orderby sort=3D"ASC">name</orderby>

        </CollectionDescriptor>

     </ClassDescriptor>



  =
-------------------------------------------------------------------------=
---------------------

  public class PermissionImpl implements Permission, Serializable=20

  {



              private Collection roles;

             =20

              public PermissionImpl()

              {}

             =20

              public PermissionImpl(Long id, String name, String =
description)

              {

                          this.id =3D id;

                          this.name =3D name;

                          this.description =3D description;

              }



  ...



      public Collection getRoles()

      {

          return roles;

      }



      public void setRoles(Collection roles)

      {

          this.roles =3D roles;

      }

  }



  =
-------------------------------------------------------------------------=
---------------------

  public class RoleImpl implements Role, Serializable

  {



              private Long parentId;

              private Collection permissions;



              public RoleImpl()=20

              {}

             =20

              public RoleImpl(Long id, String name, String description, =
Long parentId)=20

              {

                          this.id =3D id;

                          this.name =3D name;

                          this.description =3D description;

                          this.parentId =3D parentId;

              }

             =20

  ...

              /**

               * @see Role#setParentId(Long)

               */

              public void setParentId(Long Id)

              {

                          this.parentId =3D id;

              }

              /**

               * @see Role#getParentId()

               */

              public Long getParentId()

              {

                          return parentId;

              }

             =20

              /**

               * @see Role#getPermissions()

               */

              public Collection getPermissions()

              {

                          return permissions;

              }

             =20

              /**

               * @see Role#setPermissions(Collection)

               */

              public void setPermissions(Collection permissions)

              {

                          this.permissions =3D permissions;

              }

  }          =20

  =
-------------------------------------------------------------------------=
---------------------

[OJB-developers] non-decomposed m:n-mappings update problem

[Hoang, H. <Hai...@co...>]

I've a many-to-many relationship as shown by the following tables,
repository.xml, and the java files:

 

The problems I encountered:

 

1.	Update the Role object to include the permissions collection doesn't
work
2.	Update the parentId on the role object doesn't work
3.	What is this tag
<inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids> means?

----------------------------------------------------------------------------
------------------

HTG_PERMISSION

HTG_ROLE

HTG_ROLE_PERMISSION

----------------------------------------------------------------------------
------------------

And the repository.xml file:

 

   <ClassDescriptor id="1">

      <class.name>com.htg.base.bo.PermissionImpl</class.name>

      <table.name>htg_permission</table.name>

      <FieldDescriptor id="1">

         <field.name>id</field.name>

         <column.name>permission_id</column.name>

         <jdbc_type>BIGINT</jdbc_type>

         <PrimaryKey>true</PrimaryKey>

         <autoincrement>true</autoincrement>

      </FieldDescriptor>

      <FieldDescriptor id="2">

         <field.name>name</field.name>

         <column.name>permission_name</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <FieldDescriptor id="3">

         <field.name>description</field.name>

         <column.name>description</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <CollectionDescriptor id="1">

         <cdfield.name>roles</cdfield.name>

         <items.class>com.htg.base.bo.RoleImpl</items.class>

         <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>

         <indirection_table>htg_role_permission</indirection_table>

 
<fks_pointing_to_this_class>permission_id</fks_pointing_to_this_class>

         <fks_pointing_to_items_class>role_id</fks_pointing_to_items_class>

         <auto.retrieve>true</auto.retrieve>

         <auto.update>false</auto.update>

         <auto.delete>false</auto.delete>

         <orderby sort="ASC">name</orderby>

      </CollectionDescriptor>

   </ClassDescriptor>

 

   <ClassDescriptor id="2">

      <class.name>com.htg.base.bo.RoleImpl</class.name>

      <table.name>htg_role</table.name>

      <FieldDescriptor id="1">

         <field.name>id</field.name>

         <column.name>role_id</column.name>

         <jdbc_type>BIGINT</jdbc_type>

         <PrimaryKey>true</PrimaryKey>

         <autoincrement>true</autoincrement>

      </FieldDescriptor>

      <FieldDescriptor id="2">

         <field.name>name</field.name>

         <column.name>role_name</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <FieldDescriptor id="3">

         <field.name>description</field.name>

         <column.name>description</column.name>

         <jdbc_type>VARCHAR</jdbc_type>

      </FieldDescriptor>

      <FieldDescriptor id="4">

         <field.name>parentId</field.name>

         <column.name>parent_id</column.name>

         <jdbc_type>BIGINT</jdbc_type>

      </FieldDescriptor>

      <CollectionDescriptor id="1">

         <cdfield.name>permissions</cdfield.name>

         <items.class>com.htg.base.bo.PermissionImpl</items.class>

         <inverse_fk_descriptor_ids>999</inverse_fk_descriptor_ids>

         <indirection_table>htg_role_permission</indirection_table>

         <fks_pointing_to_this_class>role_id</fks_pointing_to_this_class>

 
<fks_pointing_to_items_class>permission_id</fks_pointing_to_items_class>

         <auto.retrieve>true</auto.retrieve>

         <auto.update>true</auto.update>

         <auto.delete>false</auto.delete>

         <orderby sort="ASC">name</orderby>

      </CollectionDescriptor>

   </ClassDescriptor>

 

----------------------------------------------------------------------------
------------------

public class PermissionImpl implements Permission, Serializable 

{

 

            private Collection roles;

            

            public PermissionImpl()

            {}

            

            public PermissionImpl(Long id, String name, String description)

            {

                        this.id = id;

                        this.name = name;

                        this.description = description;

            }

 

...

 

    public Collection getRoles()

    {

        return roles;

    }

 

    public void setRoles(Collection roles)

    {

        this.roles = roles;

    }

}

 

----------------------------------------------------------------------------
------------------

public class RoleImpl implements Role, Serializable

{

 

            private Long parentId;

            private Collection permissions;

 

            public RoleImpl() 

            {}

            

            public RoleImpl(Long id, String name, String description, Long
parentId) 

            {

                        this.id = id;

                        this.name = name;

                        this.description = description;

                        this.parentId = parentId;

            }

            

...

            /**

             * @see Role#setParentId(Long)

             */

            public void setParentId(Long Id)

            {

                        this.parentId = id;

            }

            /**

             * @see Role#getParentId()

             */

            public Long getParentId()

            {

                        return parentId;

            }

            

            /**

             * @see Role#getPermissions()

             */

            public Collection getPermissions()

            {

                        return permissions;

            }

            

            /**

             * @see Role#setPermissions(Collection)

             */

            public void setPermissions(Collection permissions)

            {

                        this.permissions = permissions;

            }

}           

----------------------------------------------------------------------------
------------------

 

[OJB-developers] LockNotGrantedException

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

Hi,

I just wanted to raise a little design issue. Is there a reason why
LockNotGrantedException is a Runtime-Exception. I think that developers
should actually be obliged to catch this exception.
Any comments?

Cheers

Georg

[OJB-developers] Collections problem..

[Andrew P. <api...@op...>]

Howdy,

I seem to be having a bit of trouble storing collections.  I've got a Site object that contains
an ArrayList of CollectionPoint objects.  Each CollectionPoint also has reference back to it's
parent Site object. When I create a Site and add a single CollectionPoint to it and persist the 
Site, it seems that the CollectionPoint object is being inserted twice into the database resulting
in a primary key violation.  I've narrowed it down a little and it seems that the ObjectEnvelopeTable
iterates over both the Site and CollectionPoint calling commit on both.  The problem seems to be that 
while persisting the Site, the CollectionPoint is persisted via storeCollections(..), and 
is then persisted again by the ObjectEvelopeTable.

This is my first OJB project so I'm not sure if I've screwed things up.  I checked out of cvs just a 
few minutes ago so I should be the latest source.  I've attached the output trace and my respositry.xml
just in case I've done something crazy..

Also, I was just wondering if references could be implemented  (theoretically speaking) without using a
distinct ID field in the referring object, ie My CollectionPoint must have a Site attribute and a siteId 
attribute, I'd love to ditch the siteId.  Please feel free to call me an idiot if I've overlooked the
obvious.. I just thought it would be a nice to have.. (c:

Keep up the excellent work!!

Thanks
Andrew

AW: [OJB-developers] Let's fix the testsuite!

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

Hi Oleg,

Oleg wrote:
> Hi!
> 
> I decided to investigate why "build junit" output looks so bad, 
> since this makes me nervous :)

good idea!

> BTW "build junit2" output is even worse on the second run.
> Here's what I found:
> 1) Several messages
> ERROR: Ignoring unknown Element orderby
> that are not counted as errors, this is probably due to 
> changes in syntax of 
> repository.xml
> 

right! These messages will disappear after my next checkin of the new
repository grammar.

> 2) A bunch of exceptions like
> java.sql.SQLException: Violation of unique index in statement 
> [INSERT INTO 
> PERSON_PROJECT (PROJECT_ID,PERSON_ID) VALUES (1,1)]
> They are not counted as errors, but they makes impression 
> that something goes 
> wrong. Actually this is just a way how OJB stores M:N 
> relations: it tries to 
> insert all records into an indirection table and ignores SQL 
> exceptions 
> telling that the record exists, 
> see 
> PersistenceBrokerImpl.storeMtoNImplementor()
> But JdbcAccess.executeUpdateSQL() logs these exceptions at 
> ERROR level.
> Something should be changed here. 

In my first draft I simply suppressed the respective error messages. But
this can't be the final solution!

> Of course it would be better to insert only new records and 
> not to ignore SQL 
> exceptions. 

I agree!

> But maybe there are some problems with this?

I don't see any. in storeMtoNImplementor() we should check if an entry
already exists. If so do nothing, else insert a new entry.

> BTW I wonder if the current algorithm works when some link 
> between Persons 
> and Projects is removed. 
> 

Currently there is no support to remove m:n entries automatically. They have
to be deleted manually.

> 3) Several errors "Object has been modified by someone else"
> I am not yet familiar with locking stuff, so could somebody 
> look into this?
> 

(Jakob answered on this already)

> 4) Table not found: ELVIS 
> I found this name in OdmgExamples.testBrokerCrash()
> so I don't know if this error is expected, 

Right that's an expected error: in testBrokerCrash() I'm provoking a Crash
of the broker (by using an unknown table 'ELVIS') to check the ODMG
Transaction abort mechanisms.

> but there are 3 
> failures and 
> 1 error for ODMG tests, and I don't see other error messages.
> 

That's bad! The last I performed the ODMG Junit tests I had 0 errors and 0
failures. These things must be fixed!

> 5) AssertionFailedError in 
> SodaExamples.testWithFakedQueryPreEmptUnlimited() 
> Any comments?
> 

Mhh, I don't know of any bug in the SODA stuff. The last time I checked it
was OK. 
When I'm finished with my changes to the repository syntax, I'll be able to
run JUnit tests again.
I'll have a look at 4. and 5. then!

cheers,

Thomas


> Thanks in advance,
>  Oleg
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 

Re: [OJB-developers] Let's fix the testsuite!

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

hi oleg,

i can only comment 3.)
> 3) Several errors "Object has been modified by someone else"
> I am not yet familiar with locking stuff, so could somebody look into
this?

in this test an OptimisticLockException has to be thrown if everything is
ok, but to avoid confusion it probably should not show up in the console.

regards,
jakob

----- Original Message -----
From: "Oleg Nitz" <on...@uk...>
To: <obj...@so...>
Sent: Tuesday, May 28, 2002 1:00 AM
Subject: [OJB-developers] Let's fix the testsuite!


> Hi!
>
> I decided to investigate why "build junit" output looks so bad,
> since this makes me nervous :)
> BTW "build junit2" output is even worse on the second run.
> Here's what I found:
> 1) Several messages
> ERROR: Ignoring unknown Element orderby
> that are not counted as errors, this is probably due to changes in syntax
of
> repository.xml
>
> 2) A bunch of exceptions like
> java.sql.SQLException: Violation of unique index in statement [INSERT INTO
> PERSON_PROJECT (PROJECT_ID,PERSON_ID) VALUES (1,1)]
> They are not counted as errors, but they makes impression that something
goes
> wrong. Actually this is just a way how OJB stores M:N relations: it tries
to
> insert all records into an indirection table and ignores SQL exceptions
> telling that the record exists, see
> PersistenceBrokerImpl.storeMtoNImplementor()
> But JdbcAccess.executeUpdateSQL() logs these exceptions at ERROR level.
> Something should be changed here.
> Of course it would be better to insert only new records and not to ignore
SQL
> exceptions.
> But maybe there are some problems with this?
> BTW I wonder if the current algorithm works when some link between Persons
> and Projects is removed.
>
> 3) Several errors "Object has been modified by someone else"
> I am not yet familiar with locking stuff, so could somebody look into
this?
>
> 4) Table not found: ELVIS
> I found this name in OdmgExamples.testBrokerCrash()
> so I don't know if this error is expected, but there are 3 failures and
> 1 error for ODMG tests, and I don't see other error messages.
>
> 5) AssertionFailedError in
SodaExamples.testWithFakedQueryPreEmptUnlimited()
> Any comments?
>
> Thanks in advance,
>  Oleg
>
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

[OJB-developers] Let's fix the testsuite!

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

Hi!

I decided to investigate why "build junit" output looks so bad, 
since this makes me nervous :)
BTW "build junit2" output is even worse on the second run.
Here's what I found:
1) Several messages
ERROR: Ignoring unknown Element orderby
that are not counted as errors, this is probably due to changes in syntax of 
repository.xml

2) A bunch of exceptions like
java.sql.SQLException: Violation of unique index in statement [INSERT INTO 
PERSON_PROJECT (PROJECT_ID,PERSON_ID) VALUES (1,1)]
They are not counted as errors, but they makes impression that something goes 
wrong. Actually this is just a way how OJB stores M:N relations: it tries to 
insert all records into an indirection table and ignores SQL exceptions 
telling that the record exists, see 
PersistenceBrokerImpl.storeMtoNImplementor()
But JdbcAccess.executeUpdateSQL() logs these exceptions at ERROR level.
Something should be changed here. 
Of course it would be better to insert only new records and not to ignore SQL 
exceptions. 
But maybe there are some problems with this?
BTW I wonder if the current algorithm works when some link between Persons 
and Projects is removed. 

3) Several errors "Object has been modified by someone else"
I am not yet familiar with locking stuff, so could somebody look into this?

4) Table not found: ELVIS 
I found this name in OdmgExamples.testBrokerCrash()
so I don't know if this error is expected, but there are 3 failures and 
1 error for ODMG tests, and I don't see other error messages.

5) AssertionFailedError in SodaExamples.testWithFakedQueryPreEmptUnlimited() 
Any comments?

Thanks in advance,
 Oleg

[OJB-developers] DListImpl remove

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

Hi Thomas,

It seems, that the remove method in DListImpl is not fully implemented.
First of all the entry never gets deleted from the entry list, the size
isn't reduced by one and
although it says in the comment above the method, that when removing an
element the index of the subsequent elements will be shifted to the left,
the code for doing that is not there. The following lines show how I
corrected that (unfortunately I can't send a diff, because DListImpl is
still one of those files that have extra line feeds in the repository).


        if (tx != null)
        {

            tx.markDelete(entry);

        }

==> added from here on

	this.size--;
        elements.remove(index);
	// changing the position markers of entries:
        int offset = 0;
        try
        {
            offset = ((DListEntry) elements.get(index)).getPosition();
        }
        catch (Exception ignored)
        {
        }
        for (int i = offset; i < elements.size(); i++)
        {
            entry = (DListEntry) elements.get(i);
            entry.setPosition(i);
        }

==> end of added code


        return entry.getRealSubject();

Cheers

Georg

Re: Antwort: Re: [OJB-developers] Fresh Checkout - JDO Problem?

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

hi,

the jdo.jars are now binaries

jakob
----- Original Message -----
From: <Joa...@tp...>
To: <obj...@li...>
Sent: Monday, May 27, 2002 9:37 AM
Subject: Antwort: Re: [OJB-developers] Fresh Checkout - JDO Problem?


> Its not really difficult. Just
> - do a "cvs admin -kb <affected files>"
> - commit a fresh version of the libraries
> - let everyone do a fresh checkout of the affected libraries. (delete
> local copy & update the lib-directory)
>
> I've done the first part, but I don't want to create a new account at sun
> to download the jars necessary for the second step, so I'd ask someone
> else to do the second step.
>
> regards
> Joachim Sauer
>
>
>
>
>
> David W Forslund <dw...@la...>
> Gesendet von: obj...@li...
> 27.05.2002 07:20
> Bitte antworten an David W.Forslund
>
>
>         An:     Thomas Mahler <tho...@ho...>
>         Kopie:  tr...@th...,
obj...@so...
>         Thema:  Re: [OJB-developers] Fresh Checkout - JDO Problem?
>
> I don't believe you can change the existing file type after it is
> stored. The CVS manual describes the 5-6 step process to correct
> a file that has been stored in the wrong type.
>
> Dave
>
> Thomas Mahler writes:
>  > Hi Travis,
>  >
>  > tr...@th... wrote:
>  >
>  > > Doh!  my bad, sorry guys.
>  > >
>  > > Maybe we should just ask sourceforge to delete those files?  would
> that help?
>  > >
>  >
>  >
>  >
>  > I don't think this is necessary. It's sufficient to set the binary
>  > attribute on those jar with the cvs command line.
>  >
>  > The problem Matthew E. is reporting here is due to a broken second
>  > check-in of those two jars by Matthew Baird.
>  >
>  > Thomas
>  >
>  >
>  > > Travis
>  > >
>  > > ---- Original Message ----
>  > > From: "Matthew E. Porter" <ma...@li...>
>  > > Sent: 2002-05-25
>  > > To: obj...@li...
>  > > Subject: [OJB-developers] Fresh Checkout - JDO Problem?
>  > >
>  > > I just performed a fresh checkout from cvs and it appears that the
>  > > jdo.jar is still not correct.  I am receiving complaints about
> missing
>  > > classes, such as javax.jdo.PersistenceManager.  If this problem
>  > > originates from jar files being checked in as text files, is anyone
>  > > opposed to setting the cvswrappers to force all jar files in binary
>  > > mode.  This is probably the simplest way to enforce this.  Or am I
> doing
>  > > something wrong that is causing the system not to build?
>  > >
>  > >
>  > > -matthew porter
>  > >
>  > >
>  > > _______________________________________________________________
>  > >
>  > > Don't miss the 2002 Sprint PCS Application Developer's Conference
>  > > August 25-28 in Las Vegas --
http://devcon.sprintpcs.com/adp/index.cfm
>  > >
>  > > _______________________________________________
>  > > 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
>  > >
>  > >
>  > >
>  > >
>  >
>  >
>  >
>  > _______________________________________________________________
>  >
>  > Don't miss the 2002 Sprint PCS Application Developer's Conference
>  > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>  >
>  > _______________________________________________
>  > Objectbridge-developers mailing list
>  > Obj...@li...
>  > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Antwort: Re: [OJB-developers] Fresh Checkout - JDO Problem?

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

Its not really difficult. Just 
- do a "cvs admin -kb <affected files>"
- commit a fresh version of the libraries
- let everyone do a fresh checkout of the affected libraries. (delete 
local copy & update the lib-directory)

I've done the first part, but I don't want to create a new account at sun 
to download the jars necessary for the second step, so I'd ask someone 
else to do the second step.

regards
Joachim Sauer





David W Forslund <dw...@la...>
Gesendet von: obj...@li...
27.05.2002 07:20
Bitte antworten an David W.Forslund

 
        An:     Thomas Mahler <tho...@ho...>
        Kopie:  tr...@th..., obj...@so...
        Thema:  Re: [OJB-developers] Fresh Checkout - JDO Problem?

I don't believe you can change the existing file type after it is
stored. The CVS manual describes the 5-6 step process to correct
a file that has been stored in the wrong type.

Dave

Thomas Mahler writes:
 > Hi Travis,
 > 
 > tr...@th... wrote:
 > 
 > > Doh!  my bad, sorry guys. 
 > > 
 > > Maybe we should just ask sourceforge to delete those files?  would 
that help?
 > > 
 > 
 > 
 > 
 > I don't think this is necessary. It's sufficient to set the binary 
 > attribute on those jar with the cvs command line.
 > 
 > The problem Matthew E. is reporting here is due to a broken second 
 > check-in of those two jars by Matthew Baird.
 > 
 > Thomas
 > 
 > 
 > > Travis
 > > 
 > > ---- Original Message ----
 > > From: "Matthew E. Porter" <ma...@li...>
 > > Sent: 2002-05-25
 > > To: obj...@li...
 > > Subject: [OJB-developers] Fresh Checkout - JDO Problem?
 > > 
 > > I just performed a fresh checkout from cvs and it appears that the 
 > > jdo.jar is still not correct.  I am receiving complaints about 
missing 
 > > classes, such as javax.jdo.PersistenceManager.  If this problem 
 > > originates from jar files being checked in as text files, is anyone 
 > > opposed to setting the cvswrappers to force all jar files in binary 
 > > mode.  This is probably the simplest way to enforce this.  Or am I 
doing 
 > > something wrong that is causing the system not to build?
 > > 
 > > 
 > > -matthew porter
 > > 
 > > 
 > > _______________________________________________________________
 > > 
 > > Don't miss the 2002 Sprint PCS Application Developer's Conference
 > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 > > 
 > > _______________________________________________
 > > 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
 > > 
 > > 
 > > 
 > > 
 > 
 > 
 > 
 > _______________________________________________________________
 > 
 > Don't miss the 2002 Sprint PCS Application Developer's Conference
 > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 > 
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

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

Re: [OJB-developers] Fresh Checkout - JDO Problem?

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

I don't believe you can change the existing file type after it is
stored. The CVS manual describes the 5-6 step process to correct
a file that has been stored in the wrong type.

Dave

Thomas Mahler writes:
 > Hi Travis,
 > 
 > tr...@th... wrote:
 > 
 > > Doh!  my bad, sorry guys. 
 > > 
 > > Maybe we should just ask sourceforge to delete those files?  would that help?
 > > 
 > 
 > 
 > 
 > I don't think this is necessary. It's sufficient to set the binary 
 > attribute on those jar with the cvs command line.
 > 
 > The problem Matthew E. is reporting here is due to a broken second 
 > check-in of those two jars by Matthew Baird.
 > 
 > Thomas
 > 
 > 
 > > Travis
 > > 
 > > ---- Original Message ----
 > > From: "Matthew E. Porter" <ma...@li...>
 > > Sent: 2002-05-25
 > > To: obj...@li...
 > > Subject: [OJB-developers] Fresh Checkout - JDO Problem?
 > > 
 > > I just performed a fresh checkout from cvs and it appears that the 
 > > jdo.jar is still not correct.  I am receiving complaints about missing 
 > > classes, such as javax.jdo.PersistenceManager.  If this problem 
 > > originates from jar files being checked in as text files, is anyone 
 > > opposed to setting the cvswrappers to force all jar files in binary 
 > > mode.  This is probably the simplest way to enforce this.  Or am I doing 
 > > something wrong that is causing the system not to build?
 > > 
 > > 
 > > -matthew porter
 > > 
 > > 
 > > _______________________________________________________________
 > > 
 > > Don't miss the 2002 Sprint PCS Application Developer's Conference
 > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 > > 
 > > _______________________________________________
 > > 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
 > > 
 > > 
 > > 
 > > 
 > 
 > 
 > 
 > _______________________________________________________________
 > 
 > Don't miss the 2002 Sprint PCS Application Developer's Conference
 > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
 > 
 > _______________________________________________
 > Objectbridge-developers mailing list
 > Obj...@li...
 > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers

Re: [OJB-developers] Fresh Checkout - JDO Problem?

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

Hi Travis,

tr...@th... wrote:

> Doh!  my bad, sorry guys. 
> 
> Maybe we should just ask sourceforge to delete those files?  would that help?
> 



I don't think this is necessary. It's sufficient to set the binary 
attribute on those jar with the cvs command line.

The problem Matthew E. is reporting here is due to a broken second 
check-in of those two jars by Matthew Baird.

Thomas


> Travis
> 
> ---- Original Message ----
> From: "Matthew E. Porter" <ma...@li...>
> Sent: 2002-05-25
> To: obj...@li...
> Subject: [OJB-developers] Fresh Checkout - JDO Problem?
> 
> I just performed a fresh checkout from cvs and it appears that the 
> jdo.jar is still not correct.  I am receiving complaints about missing 
> classes, such as javax.jdo.PersistenceManager.  If this problem 
> originates from jar files being checked in as text files, is anyone 
> opposed to setting the cvswrappers to force all jar files in binary 
> mode.  This is probably the simplest way to enforce this.  Or am I doing 
> something wrong that is causing the system not to build?
> 
> 
> -matthew porter
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> 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] replace crimson with xerces

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

Hi Travis,

tr...@th... wrote:

> Just a thought, but maybe xerces should take the place of crimson as the parser as crimson seems a little a dated.  
> 


The only reason why I used Crimson was size:
Crimson.jar is about 200KB
The two required Xerces jar together are about 1.8MB (that's more than 
whole OJB src distribution !)

We are not doing sophisticated parsing stuff, so Crimson is pretty OK 
for our needs.
If anyone prefers to use Xerces instead he can so by just replacing 
Crimson.jar by the two Xerces jars xercesImpl.jar and xmlParserAPIs.jar.


cheers,

Thomas


> Travis 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
> 

[OJB-developers] replace crimson with xerces

[<tr...@th...>]

Just a thought, but maybe xerces should take the place of crimson as the parser as crimson seems a little a dated.  

Travis 

RE: [OJB-developers] Fresh Checkout - JDO Problem?

[<tr...@th...>]

Doh!  my bad, sorry guys. 

Maybe we should just ask sourceforge to delete those files?  would that help?

Travis

---- Original Message ----
From: "Matthew E. Porter" <ma...@li...>
Sent: 2002-05-25
To: obj...@li...
Subject: [OJB-developers] Fresh Checkout - JDO Problem?

I just performed a fresh checkout from cvs and it appears that the 
jdo.jar is still not correct.  I am receiving complaints about missing 
classes, such as javax.jdo.PersistenceManager.  If this problem 
originates from jar files being checked in as text files, is anyone 
opposed to setting the cvswrappers to force all jar files in binary 
mode.  This is probably the simplest way to enforce this.  Or am I doing 
something wrong that is causing the system not to build?


-matthew porter


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

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