Re: delete relation in indirection-table

2004-03-04 Thread Klaus Ripplinger

Hi Olivier, Hi Edson,

using MangeableVector solved the problem!
thanks a lot!

Klaus



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



Re: delete relation in indirection-table

2004-03-04 Thread Armin Waibel
Hi all,

is this behaviour documented?

regards,
Armin
Klaus Ripplinger wrote:
Hi Olivier, Hi Edson,

using MangeableVector solved the problem!
thanks a lot!
Klaus



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


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


un outil interessant pour la supervission des statment JDBC

2004-03-04 Thread Reda Benzair
suite à une discution dans OJB forum
il y un autil tres interessant Open Source pour la suppervission au 
niveau du JDBC
interessant de voir ça si en peut l'integer chez nous
http://www.irongrid.com/catalog/product_info.php?products_id=32

Charles Anthony wrote:

Hi, 

I'm not sure if you are aware, but there is already a tool to do this, based
on the p6spy jdbc driver.
It's available under the Apache license too.
I believe the only thing it doesn't do is the analysis of the data to
suggest indices.
http://www.irongrid.com/catalog/product_info.php?products_id=32

I've only glanced at the tool, not used it.

Even if that tool is not what you want, it's probably better to extend the
p6spy driver  to do what you want - as it would be applicable across all
environments that use jdbc
Cheers,

Charles.

 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 03 March 2004 08:32
To: [EMAIL PROTECTED]
Subject: Logging SQL for automatic index generation or performance
Analysation ?
Hi,

I would like to know where the best place would be to hook 
into ojb a class
which logs all sql statements sent to the DB.

My idea is to analyze the from and where clause and log into 
a database
table the actual statements used in a live system. I then 
would like to
write a tool which analyzes this table and suggests the 
best indices to
create on the database.

To make sure I really catch all statements I would like to 
directly hook
into ojb. Also, this could then easily be re-used.

We thought about a trace but the amount of data just seems to big.

Any ideas / suggestions ?

Thanks,
 Stefan Schlösser
--
---
I N T E R M E D I A T E GmbH  Co. KG
eSolutions  Integration
Durmersheimer Straße 55 t +49 (0)721.98644-50
76185 Karlsruhe f +49 (0)721.98644-99
http://www.intermediate.de
P.S. Als Beratungs- und Systemhaus optimiert Intermediate die
Geschäftsprozesse mittelständischer Unternehmen in Vertrieb,
Marketing und Kundenservice.
Tätigkeitsschwerpunkte sind Angebots- und Produkt-Konfiguration
sowie Enterprise Content-Management-Systeme.
Unsere besondere Stärke liegt in der Integration bestehender
Systeme, insbesondere von ERP-Systemen wie SAP R/3, BRAIN AS,
MAS90 etc.


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



___
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer 



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



--
*Reda BENZAIR**
*Software Analyst
***
*Phone: +33 (0)1 4996 6324
Fax: +33 (0)1 4996 6405
Mobile: +33 (0)6 6240 6192
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Sorry error to forward message !

2004-03-04 Thread Reda Benzair
Reda Benzair wrote:

suite à une discution dans OJB forum
il y un autil tres interessant Open Source pour la suppervission au 
niveau du JDBC
interessant de voir ça si en peut l'integer chez nous
http://www.irongrid.com/catalog/product_info.php?products_id=32

Charles Anthony wrote:

Hi,
I'm not sure if you are aware, but there is already a tool to do 
this, based
on the p6spy jdbc driver.
It's available under the Apache license too.

I believe the only thing it doesn't do is the analysis of the data to
suggest indices.
http://www.irongrid.com/catalog/product_info.php?products_id=32

I've only glanced at the tool, not used it.

Even if that tool is not what you want, it's probably better to 
extend the
p6spy driver  to do what you want - as it would be applicable across all
environments that use jdbc

Cheers,

Charles.

 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 03 March 2004 08:32
To: [EMAIL PROTECTED]
Subject: Logging SQL for automatic index generation or performance
Analysation ?
Hi,

I would like to know where the best place would be to hook into ojb 
a class
which logs all sql statements sent to the DB.

My idea is to analyze the from and where clause and log into a database
table the actual statements used in a live system. I then would like to
write a tool which analyzes this table and suggests the best 
indices to
create on the database.

To make sure I really catch all statements I would like to directly 
hook
into ojb. Also, this could then easily be re-used.

We thought about a trace but the amount of data just seems to big.

Any ideas / suggestions ?

Thanks,
 Stefan Schlösser
--
---
I N T E R M E D I A T E GmbH  Co. KG
eSolutions  Integration
Durmersheimer Straße 55 t +49 (0)721.98644-50
76185 Karlsruhe f +49 (0)721.98644-99
http://www.intermediate.de
P.S. Als Beratungs- und Systemhaus optimiert Intermediate die
Geschäftsprozesse mittelständischer Unternehmen in Vertrieb,
Marketing und Kundenservice.
Tätigkeitsschwerpunkte sind Angebots- und Produkt-Konfiguration
sowie Enterprise Content-Management-Systeme.
Unsere besondere Stärke liegt in der Integration bestehender
Systeme, insbesondere von ERP-Systemen wie SAP R/3, BRAIN AS,
MAS90 etc.


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


___
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 





--
*Reda BENZAIR**
*Software Analyst
***
*Phone: +33 (0)1 4996 6324
Fax: +33 (0)1 4996 6405
Mobile: +33 (0)6 6240 6192
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: [OTM] bi-directional 1:n not working (still not working)

2004-03-04 Thread Weaver, Scott
I am now using tandem test cases to simulate the shutdown of the system and
a restart, i.e. no cached items.

I run the identical fetching tests in the second test case as I do in the
first (only the first case creates the test data).  Everything works in the
first case but after restart the second test fails AND errors.  The failure
is caused by the WebApp not being materialized into its parent, the error is
caused in the teardown() were I try and clean up the test data (see
sys.out.txt for more details).

I wrote the test cases using straight OTM, using OTMExamples as a guide;
triple check that it wasn't something my abstraction layer was doing
incorrectly.

Regards,
** 
| Scott T Weaver |
| [EMAIL PROTECTED]| 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
**

 -Original Message-
 From: Coup, Robert Muir [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 03, 2004 6:02 PM
 To: OJB Users List
 Subject: RE: [OTM] bi-directional 1:n not working
 
 Any chance you could post a summary of what you learnt?
 
 Thanks,
 
 Rob :)
 
  -Original Message-
  From: Weaver, Scott [mailto:[EMAIL PROTECTED]
  Sent: Thursday, 4 March 2004 11:48 a.m.
  To: 'OJB Users List'
  Subject: RE: [OTM] bi-directional 1:n not working
 
  Hi Oleg,
 
  I had a long IM conversation with Matt Baird today and he set
  me straight on how to use OTM and otm-dependent.  However, I
  am still getting the NullPointerExceptions when invalidating
  or using the empty cache impl (see my other posts).
 
 
  Regards,
  **
  | Scott T Weaver |
  | [EMAIL PROTECTED]|
  | Apache Jetspeed Portal Project |
  | Apache Pluto Portlet Container |
  **
 
   -Original Message-
   From: Oleg Nitz [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, March 03, 2004 6:58 PM
   To: OJB Users List
   Subject: Re: [OTM] bi-directional 1:n not working
  
   On Wednesday 03 March 2004 16:50, Weaver, Scott wrote:
Removing these appears to have fixed this:
   
auto-delete=true
auto-update=true
auto-retrieve=true
   
I thought OTM could co-exists with these settings?  I
  guess I was wrong.
  
   auto-retrieve=true is okay
   AFAIK auto-update=true and auto-delete=true are okay,
  unless you
   set otm-dependent=true. When you add otm-dependent=true
   don't
   forget to remove auto-update=true and auto-delete=true.
   Anyway I don't understand how auto-update=true can affect setting
   object references to parents.
  
   Regards,
Oleg
  
  
  
  -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

java.lang.NullPointerException
at org.apache.ojb.broker.accesslayer.CollectionPrefetcher.associateBatch
ed(CollectionPrefetcher.java:190)
at org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship
(BasePrefetcher.java:150)
at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks
(QueryReferenceBroker.java:316)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(
QueryReferenceBroker.java:185)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(
QueryReferenceBroker.java:242)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(
QueryReferenceBroker.java:262)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery
(PersistenceBrokerImpl.java:1093)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB
yQuery(DelegatingPersistenceBroker.java:322)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionB
yQuery(DelegatingPersistenceBroker.java:322)
at org.apache.ojb.otm.core.BaseConnection.getCollectionByQuery(BaseConne
ction.java:277)
at org.apache.ojb.otm.core.BaseConnection.getCollectionByQuery(BaseConne
ction.java:292)
at org.apache.jetspeed.components.portletregistry.TestRegistryDirectOTMP
art2.tearDown(TestRegistryDirectOTMPart2.java:146)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at 

RE: [OTM] bi-directional 1:n not working (still not working)

2004-03-04 Thread Weaver, Scott
Bad day for attachments.  This is correct second test case, ignore
TestRegistryDirectPart2.

Regards,
** 
| Scott T Weaver |
| [EMAIL PROTECTED]| 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
**

 -Original Message-
 From: Weaver, Scott [mailto:[EMAIL PROTECTED]
 Sent: Thursday, March 04, 2004 10:55 AM
 To: 'OJB Users List'
 Subject: RE: [OTM] bi-directional 1:n not working (still not working)
 
 Rest of the test stuff, had to append .txt to everything because the
 list
 server filters are so anal ;)  Hopefully they get through.
 
 Regrads,
 **
 | Scott T Weaver |
 | [EMAIL PROTECTED]|
 | Apache Jetspeed Portal Project |
 | Apache Pluto Portlet Container |
 **
 
  -Original Message-
  From: Weaver, Scott [mailto:[EMAIL PROTECTED]
  Sent: Thursday, March 04, 2004 10:52 AM
  To: 'OJB Users List'
  Subject: RE: [OTM] bi-directional 1:n not working (still not working)
 
  I am now using tandem test cases to simulate the shutdown of the system
  and
  a restart, i.e. no cached items.
 
  I run the identical fetching tests in the second test case as I do in
 the
  first (only the first case creates the test data).  Everything works in
  the
  first case but after restart the second test fails AND errors.  The
  failure
  is caused by the WebApp not being materialized into its parent, the
 error
  is
  caused in the teardown() were I try and clean up the test data (see
  sys.out.txt for more details).
 
  I wrote the test cases using straight OTM, using OTMExamples as a guide;
  triple check that it wasn't something my abstraction layer was doing
  incorrectly.
 
  Regards,
  **
  | Scott T Weaver |
  | [EMAIL PROTECTED]|
  | Apache Jetspeed Portal Project |
  | Apache Pluto Portlet Container |
  **
 
   -Original Message-
   From: Coup, Robert Muir [mailto:[EMAIL PROTECTED]
   Sent: Wednesday, March 03, 2004 6:02 PM
   To: OJB Users List
   Subject: RE: [OTM] bi-directional 1:n not working
  
   Any chance you could post a summary of what you learnt?
  
   Thanks,
  
   Rob :)
  
-Original Message-
From: Weaver, Scott [mailto:[EMAIL PROTECTED]
Sent: Thursday, 4 March 2004 11:48 a.m.
To: 'OJB Users List'
Subject: RE: [OTM] bi-directional 1:n not working
   
Hi Oleg,
   
I had a long IM conversation with Matt Baird today and he set
me straight on how to use OTM and otm-dependent.  However, I
am still getting the NullPointerExceptions when invalidating
or using the empty cache impl (see my other posts).
   
   
Regards,
**
| Scott T Weaver |
| [EMAIL PROTECTED]|
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
**
   
 -Original Message-
 From: Oleg Nitz [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 03, 2004 6:58 PM
 To: OJB Users List
 Subject: Re: [OTM] bi-directional 1:n not working

 On Wednesday 03 March 2004 16:50, Weaver, Scott wrote:
  Removing these appears to have fixed this:
 
  auto-delete=true
  auto-update=true
  auto-retrieve=true
 
  I thought OTM could co-exists with these settings?  I
guess I was wrong.

 auto-retrieve=true is okay
 AFAIK auto-update=true and auto-delete=true are okay,
unless you
 set otm-dependent=true. When you add otm-dependent=true
 don't
 forget to remove auto-update=true and auto-delete=true.
 Anyway I don't understand how auto-update=true can affect
 setting
 object references to parents.

 Regards,
  Oleg




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

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


/* 
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2000-2003 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 

Re: Re: delete relation in indirection-table

2004-03-04 Thread Olivier NOUGUIER
Hi all,

 Nope I didn't found any thing on the subject, I found this behaviour while debugging 
ojb ( thank to eclipse ). And then reading comment in example bundled with ojb.
Same behaviour with all ( I played with ) layer ( odmg, PB ).

 It's should be documented AND specified that default collection class is 
RemovalAwareCollection ...

Really happy to give ( this insignifiant ... ) help
AND many many many thank for ojb, document in general is very well done.

 Message du 04/03/04 10:24
 De : Armin Waibel [EMAIL PROTECTED]
 A : OJB Users List [EMAIL PROTECTED]
 Copie à : 
 Objet : Re: delete relation in indirection-table
 
 Hi all,
 
 is this behaviour documented?
 
 regards,
 Armin
 
 Klaus Ripplinger wrote:
  Hi Olivier, Hi Edson,
  
  using MangeableVector solved the problem!
  thanks a lot!
 
You're very welcome ! 
  Klaus
  
 

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



Re: Re: delete relation in indirection-table

2004-03-04 Thread edson . richter
As far as I remember, this behaviour was changed since 0.96 or 0.97 - I'm not sure.
Of course, a DTD comment alerting that RemovalAwareCollection is default is very 
welcome.

And changes in DOCs, specially relative to M:N mapping, recommending to not use default
value for collection-class IMHO is mandatory.


Edson Richter


 Hi all,

  Nope I didn't found any thing on the subject, I found this behaviour while 
 debugging ojb (
 thank to eclipse ). And then reading comment in example bundled with ojb.
 Same behaviour with all ( I played with ) layer ( odmg, PB ).

  It's should be documented AND specified that default collection class is
 RemovalAwareCollection ...

 Really happy to give ( this insignifiant ... ) help
 AND many many many thank for ojb, document in general is very well done.

 Message du 04/03/04 10:24
 De : Armin Waibel [EMAIL PROTECTED]
 A : OJB Users List [EMAIL PROTECTED]
 Copie à :
 Objet : Re: delete relation in indirection-table

 Hi all,

 is this behaviour documented?

 regards,
 Armin

 Klaus Ripplinger wrote:
  Hi Olivier, Hi Edson,
 
  using MangeableVector solved the problem!
  thanks a lot!
 
 You're very welcome !
  Klaus
 
 

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




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



Re: JOIN and aliases...is this a bug?

2004-03-04 Thread Jakob Braeuchi
hi alessandro,

according to your repository db.DBAttribute contains a field called 'nname'

field-descriptor
  name=nname
  column=NAME
  primarykey=true
  jdbc-type=VARCHAR
/
there's no field called 'name'. so you can either change your repository or 
adapt your query:

Criteria c = new Criteria();
c.addEqualsTo(attributes.nname, Ale);
Query q = QueryFactory.newQuery(DBObject.class, c);
jakob

Alessandro Villamaina wrote:
Hi Jackob,
this is the class descriptor I currently use.
Thanks for help!
Alessandro

class-descriptor class=db.DBObject table=DBOBJECT
   
  field-descriptor
name=name
column=NAME
jdbc-type=VARCHAR
primarykey=true
  /
   
  collection-descriptor
name=attributes
auto-delete=true
auto-update=true
element-class-ref = db.DBAttribute
inverse-foreignkey field-ref = owner /
  /collection-descriptor
   
/class-descriptor
   
class-descriptor
   class=db.DBAttribute
   table=DBATTRIBUTE
   
   field-descriptor
 name=nname
 column=NAME
 primarykey=true
 jdbc-type=VARCHAR
   /
   
   field-descriptor
 name=vvalue
 column=VALUE
 jdbc-type=VARCHAR
   /
   
   field-descriptor
 name=owner
 column=OWNER
 jdbc-type=VARCHAR
 primarykey=true
 access=anonymous
   /
/class-descriptor

Da: Jakob Braeuchi [EMAIL PROTECTED]
Data: Fri, 20 Feb 2004 21:57:23 +0100
A: OJB Users List [EMAIL PROTECTED]
Oggetto: Re: JOIN and aliases...is this a bug?
hi alessandro,

could you please post the class-descriptors ?

jakob

Alessandro Villamaina wrote:


Hi all,

I have the following class declaration (pseudo code):

class DBObject
 private String name
 private Collection attributes
class DBAttribute
 private String name
 private String value
when I execute a query like the following (with PB API):

Criteria c = new Criteria();
c.addEqualsTo(attributes.name, Ale);
Query q = QueryFactory.newQuery(DBObject.class, c);
the generated SQL statement is

SELECT A0.NAME FROM DBOBJECT A0 JOIN DBATTRIBUTE A1 ON A0.NAME=A1.OWNER WHERE name =  'Ale';

where OWNER is the column used by OJB to maintain references between an object and its attributes as specified in the repository_user.xml.

It seems OJB forgets to use the alias A1 to qualify the attribute name in the WHERE clause; since both tables have such attribute, the query fails (using name instead of A1.name is ambiguous).

Is this a bug in OJB or am I doing something wrong?
Thanks,
Alessandro

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

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


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

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


Re: Extent problem with ODMG

2004-03-04 Thread Jakob Braeuchi
hi charles, steve,

i do not think that my fix is related to this problem. i propose to move the 
definition of the relationship to the concrete classes.

jakob

Charles Anthony wrote:

Hi,

I have a hunch - quite possibly misplaced - that this may have something to
do the bug I reported in the thhread entitled.
Criteria.setClassPath - the saga continues
Although you are using an ODMG query, when the query is parsed, it does
generate a standard QueryByCriteria. QueryByCriteria was getting the wrong
class descriptor when paths of  1 sement were used. This would lead to the
attribute name being passed to the query, as opposed to the column name.
Jakob fixed this in CVS last night.

This May Be A Red Herring.

Cheers,

Charles.


-Original Message-
From: Steve Clark [mailto:[EMAIL PROTECTED]
Sent: 03 March 2004 19:56
To: OJB Users List
Subject: Re: Extent problem with ODMG
I'm still having this problem, so I'm going to try again.

Using ODMG, RC5, Oracle 9i.

Summary:
   - Class A has a 1-to-1 relationship 'abs' to an abstract
 superclass S
   - Class S has concrete subclasses B and C
   - Classes B and C share a common relationship 'com' to another
 class D; this relationship is defined in the superclass S
   - Class D has a property 'p'
   - A, B, C, and D map to distinct tables
I am trying to retrieve all A's which have a given value for 'p' in
the D associated with the related B or C (whichever one it is).  So:
   select x from A where A.abs.com.p = ?

A.abs has type S, the abstract superclass; A.abs.com has type D.  This
means that the query needs to generate some sort of interesting join
to check for both possible paths to D (via B or C), knowing that
either B or C will have exactly one row satisfying the join
condition(s).  In pseudocode:
   select x from A where
   if A.abs instanceof B then ((B) A.abs).com.p = ?
   else if A.abs instanceof C then ((C) A.abs).com.p = ?
Should I expect this to work?  The SQL query which is being generated
is not only incorrect but invalid: OJB does not rewrite 'p', and in
fact does not even mention D at all.  I assume this has to do with
the fact that the repository doesn't record the presence of the
relationship 'com' in the abstract superclass, but only in the
subclasses.  Queries starting from B or C and following the 'com'
relationship work fine.  Am I out of luck, or is there some way I can
get a working query out of this?
thanks for any insights,
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
PS: Original message below.  Name mappings:

A = PartnerImpl
B = SubSiteImpl
C = TechAssistImpl
D = SiteImpl
S = AccomplishmentImpl
abs = accomp
com = site
p = habTypeCode
   sc I'm having a problem with extents in ODMG.  OJB is generating
   sc incorrect (and, in fact, invalid) SQL for my OQL query.  I'm
   sc using RC5.
   sc My data model consists of Sites, which have collections of
   sc each of two kinds of Accomplishments (SubSites and
   sc TechAssists).  An Accomplishment has a collection of Partners.
   sc In the reverse direction, each Partner is associated with
   sc exactly one Accomplishment (either a SubSite or a TechAssist),
   sc and an Accomplishment knows about its parent Site.  My
   sc repository looks like this:
   sc !-- - - - - - - Site - - - - - - --

   sc class-descriptor
   sc class=gov.doi.habits.dataobjects.SiteImpl
   sc table=SITE_DETAIL proxy=dynamic
   sc   field-descriptor
   sc   name=siteKey column=SITE_KEY jdbc-type=INTEGER
   sc   primarykey=true autoincrement=true/
   sc   field-descriptor
   sc   name=habTypeCode column=HAB_TYPE_CODE
   sc   jdbc-type=INTEGER /
   sc   collection-descriptor
   sc   name=subSites
   sc   
element-class-ref=gov.doi.habits.dataobjects.SubSiteImpl
   sc   
collection-class=org.apache.ojb.broker.util.collections.Manag
eableArrayList
   sc inverse-foreignkey field-ref=siteKey /
   sc   /collection-descriptor

   sc   collection-descriptor
   sc   name=techAssists
   sc 
element-class-ref=gov.doi.habits.dataobjects.TechAssistImpl
   sc 
collection-class=org.apache.ojb.broker.util.collections.Manag
eableArrayList
   sc inverse-foreignkey field-ref=siteKey /
   sc   /collection-descriptor
   sc /class-descriptor

   sc !-- - - - - - - Accomplishment - - - - - - --

   sc class-descriptor
   sc class=gov.doi.habits.dataobjects.AccomplishmentImpl 
   sc   extent-class
   sc   class-ref=gov.doi.habits.dataobjects.SubSiteImpl /
   sc   extent-class
   sc   class-ref=gov.doi.habits.dataobjects.AssistImpl /
   sc /class-descriptor
   sc !-- - - - - - - SubSite - - - - - - --

   sc class-descriptor
   sc class=gov.doi.habits.dataobjects.SubSiteImpl
   sc table=SUB_SITE_DETAIL proxy=dynamic
   sc   field-descriptor
   sc   name=accompKey column=ACCOMP_KEY jdbc-type=INTEGER
   sc   primarykey=true autoincrement=true
   sc   sequence-name=SEQ_ACCOMP_DETAIL 

Referencing tables not in return object

2004-03-04 Thread jeichels

I am not sure how to do something and have tried a couple of approaches without 
success.   I could use some help.

My problem comes down to the idea that I want to return a mapped object but based on a 
complex query that gets messed up due to the way OJB uses foreign keys.  Is there a 
way to do a query on tables not referenced in the object you seek to return?   I want 
to return rstep1 objects (A0), but I need to create a complex query in other tables to 
get rstep1 objects.


What I would to have happened is something like:
SELECT A0.rTitle, A0.brief
FROM rstep1 A0, si A1
WHERE ((A1.targetmsid =  20001025 )
AND A1.targetmid =  20001 )
AND interestmsid = A0.msid


What I do get through OJB's use of the foreign key is:
SELECT A0.rTitle, A0.brief
FROM rstep1 A0
INNER JOIN si A1 ON A0.msid=A1.targetmsid
WHERE ((A1.targetmsid =  20001025 )
AND A1.targetmid =  20001 )
AND A1.interestmsid = A0.msid


Is there a way to create a query that returns a mapped object where tables referened 
are not held within the object?   I only want to return values rstep1, but have to 
reference another table only within the query.   The query gets messed up because of 
the foreign key used to generate the query.

I have tried below without using a reference to the si table, but si becomes ambigous.

crit.addSql(si.targetmsid =  + jMsid);
crit.addSql(si.targetmid =  + jMid);
crit.addSql(si.interestmsid = rstep1.msid);

I have tried below with references to the si table and it creates the 2nd query above 
with the incorrect INNER JOIN.

crit.addEqualTo(si.targetmsid, jMsid);
crit.addEqualTo(si.targetmid, jMid);
crit.addEqualToField(si.interestmsid, memberServiceId);

In this second case, if a reference is required, is there a way that I can not 
have an INNER JOIN on the foreign key be created.


Thank you for any help.

JohnE








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



Re: ODMG UPDATE TOO FAST: DB not updated from jboss(daemon) and tomcat

2004-03-04 Thread Sukesh Garg
Dear Thomas,

Thanks for your response. 

The DB does get updated by the JBOSS daemon. 

However, when the OJB implementation is accessed directly by tomcat
running in the same JBOSS instance, it does not update the database.

You are right that the corresponding sql update does not happen(no
corresponding sql statement). 

Interestingly, if i update a second object in the same fashion, the
previous object gets updated and but the new one is not updated.

Enclosed is the code.

query.create(subQuery +  where id =  + tvi.getId());
Transaction tx = odmg.newTransaction();
tx.begin();
DList result = (DList) query.execute();
if (!result.isEmpty()) {
ObjectName ti = (ObjectName) result.get(0);
tx.lock(ti, Transaction.WRITE);
ti.setState(tvi.getStatus());
}
tx.commit();

Would really appreciate any help...

thx,
Sukesh

btn. I have tried marking the object dirty, removing it from the cache
and using tx.checkpoint() but no help.


On Wed, 2004-03-03 at 22:57, Thomas Mahler wrote:
 Hi Sukesh,
 
 If you can see by debugging (or easier by using the P6Spy jdbc tracer) 
 that ojb executes the correct insert or update, then the problem can not 
 be cause dby cache / gc interaction.
 
 The only explanation i have for such a behaviour is that a database 
 commit is not done after executing your statement.
 
 Why could this happen? JBOSS is a fullfledged J2EE container with JTA 
 transaction manager and Tomcat isn't.
 SO under commit you must use explicit commits.
 
 Please check your OJB.properties settings that define the transactional 
 behaviour.
 
 cheeers,
 Thomas
 
 Sukesh Garg wrote:
  My application accesses OJB via the JBOSS startup daemons and TOMCAT.
  
  The database gets updated correctly when the operation is performed via
  the JBOSS daemon. 
  
  However, if the operation is performed via tomcat, the db does not get
  updated. There are no errors reported. 
  
  If I enable the debugger and put a breakpoint, then the db gets updated
  properly. It seems as if the application is too fast for the cache to
  update the database and garbage collection kicks in and cleans the
  update object.
  
  I am using ObjectCacheDefaultImpl. I tried  explicitly marking the
  object dirty but no success.
  
  Would really appreciate any help.
  
  thx,
  Sukesh
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 



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



Re: Extent problem with ODMG

2004-03-04 Thread Jakob Braeuchi
hi,

you'll have to define the relationship to D in the abstract S as well as in the 
concrete B and C. it has to be defined in S because when navigation from A the 
descriptor of class S is used to resolve the relationship.

i tried this meaningless query :

Criteria crit = new Criteria();
crit.addLike(allArticlesInGroup.productGroup.groupName, B%);
QueryByCriteria q = ueryFactory.newQuery(ProductGroupWithAbstractArticles.class, 
crit, true);

if i do not define a relationship in class InterfaceArticle to class 
ProductGroup the SQL fails. after adding reference-descriptor 
name=productGroup it worked.

...
   class-descriptor class=org.apache.ojb.broker.InterfaceArticle
  extent-class class-ref=org.apache.ojb.broker.Article /
  extent-class class-ref=org.apache.ojb.broker.BookArticle /
  extent-class class-ref=org.apache.ojb.broker.CdArticle /
  reference-descriptor
name=productGroup
class-ref=org.apache.ojb.broker.ProductGroup
  
 documentationthis is the reference to an articles 
productgroup/documentation
 foreignkey field-ref=productGroupId/
 attribute attribute-name=color attribute-value=red /
  	 attribute attribute-name=size attribute-value=tiny /
  /reference-descriptor

   /class-descriptor
...
hth
jakob
Jakob Braeuchi wrote:

hi charles, steve,

i do not think that my fix is related to this problem. i propose to move 
the definition of the relationship to the concrete classes.

jakob

Charles Anthony wrote:

Hi,

I have a hunch - quite possibly misplaced - that this may have 
something to
do the bug I reported in the thhread entitled.
Criteria.setClassPath - the saga continues

Although you are using an ODMG query, when the query is parsed, it does
generate a standard QueryByCriteria. QueryByCriteria was getting the 
wrong
class descriptor when paths of  1 sement were used. This would lead 
to the
attribute name being passed to the query, as opposed to the column name.

Jakob fixed this in CVS last night.

This May Be A Red Herring.

Cheers,

Charles.


-Original Message-
From: Steve Clark [mailto:[EMAIL PROTECTED]
Sent: 03 March 2004 19:56
To: OJB Users List
Subject: Re: Extent problem with ODMG
I'm still having this problem, so I'm going to try again.

Using ODMG, RC5, Oracle 9i.

Summary:
   - Class A has a 1-to-1 relationship 'abs' to an abstract
 superclass S
   - Class S has concrete subclasses B and C
   - Classes B and C share a common relationship 'com' to another
 class D; this relationship is defined in the superclass S
   - Class D has a property 'p'
   - A, B, C, and D map to distinct tables
I am trying to retrieve all A's which have a given value for 'p' in
the D associated with the related B or C (whichever one it is).  So:
   select x from A where A.abs.com.p = ?

A.abs has type S, the abstract superclass; A.abs.com has type D.  This
means that the query needs to generate some sort of interesting join
to check for both possible paths to D (via B or C), knowing that
either B or C will have exactly one row satisfying the join
condition(s).  In pseudocode:
   select x from A where
   if A.abs instanceof B then ((B) A.abs).com.p = ?
   else if A.abs instanceof C then ((C) A.abs).com.p = ?
Should I expect this to work?  The SQL query which is being generated
is not only incorrect but invalid: OJB does not rewrite 'p', and in
fact does not even mention D at all.  I assume this has to do with
the fact that the repository doesn't record the presence of the
relationship 'com' in the abstract superclass, but only in the
subclasses.  Queries starting from B or C and following the 'com'
relationship work fine.  Am I out of luck, or is there some way I can
get a working query out of this?
thanks for any insights,
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
PS: Original message below.  Name mappings:

A = PartnerImpl
B = SubSiteImpl
C = TechAssistImpl
D = SiteImpl
S = AccomplishmentImpl
abs = accomp
com = site
p = habTypeCode
   sc I'm having a problem with extents in ODMG.  OJB is generating
   sc incorrect (and, in fact, invalid) SQL for my OQL query.  I'm
   sc using RC5.
   sc My data model consists of Sites, which have collections of
   sc each of two kinds of Accomplishments (SubSites and
   sc TechAssists).  An Accomplishment has a collection of Partners.
   sc In the reverse direction, each Partner is associated with
   sc exactly one Accomplishment (either a SubSite or a TechAssist),
   sc and an Accomplishment knows about its parent Site.  My
   sc repository looks like this:
   sc !-- - - - - - - Site - - - - - - --

   sc class-descriptor
   sc class=gov.doi.habits.dataobjects.SiteImpl
   sc table=SITE_DETAIL proxy=dynamic
   sc   field-descriptor
   sc   name=siteKey column=SITE_KEY jdbc-type=INTEGER
   sc   primarykey=true autoincrement=true/
   sc   field-descriptor
   sc   name=habTypeCode 

Re: Extent problem with ODMG

2004-03-04 Thread Steve Clark
This did indeed solve the problem.  In summary, repository.xml has:

- Foreign key field defined in subclasses only
- Relationship defined in subclasses and in superclass

And in Java the relationship accessors are defined in the superclass
only.

I didn't even know that one could put fields or relationships in the
superclass in repository.xml.  Thanks for pointing this out, Jakob!

-- 
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291


 Jakob Braeuchi writes:

Jakob hi,

Jakob you'll have to define the relationship to D in the abstract
Jakob S as well as in the concrete B and C. it has to be defined
Jakob in S because when navigation from A the descriptor of class
Jakob S is used to resolve the relationship.

Jakob i tried this meaningless query :

Jakob Criteria crit = new Criteria();
Jakob crit.addLike(allArticlesInGroup.productGroup.groupName,
Jakob B%); QueryByCriteria q =
Jakob ueryFactory.newQuery(ProductGroupWithAbstractArticles.class,
Jakob crit, true);

Jakob if i do not define a relationship in class InterfaceArticle
Jakob to class ProductGroup the SQL fails. after adding
Jakob reference-descriptor name=productGroup it worked.

Jakob ...
Jakob class-descriptor
Jakob class=org.apache.ojb.broker.InterfaceArticle
Jakobextent-class
Jakobclass-ref=org.apache.ojb.broker.Article /
Jakobextent-class
Jakobclass-ref=org.apache.ojb.broker.BookArticle /
Jakobextent-class
Jakobclass-ref=org.apache.ojb.broker.CdArticle /

Jakobreference-descriptor
Jakob  name=productGroup
Jakob  class-ref=org.apache.ojb.broker.ProductGroup

Jakob   documentationthis is the reference to an
Jakob   articles
Jakob productgroup/documentation
Jakob   foreignkey field-ref=productGroupId/
Jakob   attribute attribute-name=color
Jakob   attribute-value=red /
Jakob   attribute attribute-name=size
Jakob   attribute-value=tiny /
Jakob/reference-descriptor

Jakob /class-descriptor
Jakob ...

Jakob hth jakob

 hi charles, steve,
 
 i do not think that my fix is related to this problem. i propose to move 
 the definition of the relationship to the concrete classes.
 
 jakob
 
 Charles Anthony wrote:
 
 Hi,

 I have a hunch - quite possibly misplaced - that this may have 
 something to
 do the bug I reported in the thhread entitled.
 Criteria.setClassPath - the saga continues

 Although you are using an ODMG query, when the query is parsed, it does
 generate a standard QueryByCriteria. QueryByCriteria was getting the 
 wrong
 class descriptor when paths of  1 sement were used. This would lead 
 to the
 attribute name being passed to the query, as opposed to the column name.

 Jakob fixed this in CVS last night.

 This May Be A Red Herring.

 Cheers,

 Charles.


 -Original Message-
 From: Steve Clark [mailto:[EMAIL PROTECTED]
 Sent: 03 March 2004 19:56
 To: OJB Users List
 Subject: Re: Extent problem with ODMG


 I'm still having this problem, so I'm going to try again.

 Using ODMG, RC5, Oracle 9i.

 Summary:
- Class A has a 1-to-1 relationship 'abs' to an abstract
  superclass S
- Class S has concrete subclasses B and C
- Classes B and C share a common relationship 'com' to another
  class D; this relationship is defined in the superclass S
- Class D has a property 'p'
- A, B, C, and D map to distinct tables

 I am trying to retrieve all A's which have a given value for 'p' in
 the D associated with the related B or C (whichever one it is).  So:

select x from A where A.abs.com.p = ?

 A.abs has type S, the abstract superclass; A.abs.com has type D.  This
 means that the query needs to generate some sort of interesting join
 to check for both possible paths to D (via B or C), knowing that
 either B or C will have exactly one row satisfying the join
 condition(s).  In pseudocode:

select x from A where
if A.abs instanceof B then ((B) A.abs).com.p = ?
else if A.abs instanceof C then ((C) A.abs).com.p = ?

 Should I expect this to work?  The SQL query which is being generated
 is not only incorrect but invalid: OJB does not rewrite 'p', and in
 fact does not even mention D at all.  I assume this has to do with
 the fact that the repository doesn't record the presence of the
 relationship 'com' in the abstract superclass, but only in the
 subclasses.  Queries starting from B or C and following the 'com'
 relationship work fine.  Am I out of luck, or is there some way I can
 get a working query out of this?

 thanks for any insights,
 Steve Clark
 Technology Applications Team
 Natural Resources Research Center/USGS
 [EMAIL PROTECTED]
 (970)226-9291

 PS: Original message below.  Name mappings:

 A = 

Re: [OTM] can not delete from dependent collection

2004-03-04 Thread Oleg Nitz
Hi Joerg,

I have fixed this issue too. You are extremely productive tester! :-)

Oleg

On Tuesday 02 March 2004 16:39, Joerg Heinicke wrote:
 My persons have a name, changing this one and making this change persistent
 does not update the database. After makePersistent(debitor) it contains
 again the original form, just like as it was not touched. The same happened
 for me for the addresses, changes on them are not saved (both removing and
 adding to an existing list and changing entries on a specific address). 


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



column name is a reserved keyword

2004-03-04 Thread Oleg Lebedev
Hi, 
 
I am changing an existing application to use OJB.
The problem that I ran into is that some of the column names are
reserved keywords, e.g. 'print'. I need to configure OJB to put all
column names in brackets, e.g. [print], when retrieving values from the
database. Otherwise, SQL Server throws a Reserved keyword exception.
 
How do I do this?
 
Thanks.
 
Oleg 
  
* 
This e-mail may contain privileged or confidential material intended for the named 
recipient only. 
If you are not the named recipient, delete this message and all attachments. 
Unauthorized reviewing, copying, printing, disclosing, or otherwise using information 
in this e-mail is prohibited. 
We reserve the right to monitor e-mail sent through our network.  
*