Re: AbstractMethodError with PostgreSQL

In einer eMail vom 16.08.2003 17:47:37 (MEZ) - Mitteleurop. Sommerze schreibt [EMAIL PROTECTED]: Hi, in the meantime I found out that my JDBC driver was too old. Using a newer one (2003-08-07) solved the problem. Christian BTW: Thomas, do you still remember me? > > In the repository_databas

RE: Compound Primary Key foreign key references

My question was the later. I could not find the behavior in the documentation. Thanks, - Dan -Original Message- From: Ron Gallagher [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 9:53 AM To: OJB Users List Subject: Re: Compound Primary Key foreign key references Dan -- A

Current OTM and JCA Adapter usability

Greetings to everyone. Is it possible to rely on current JCA adapter and OTM implementations in commercial projects? We've done some research and it seems that transaction stuff inside JCA adapter is unusable. Can someone acknowledge it or provide any comments on this issue? Thanks in advance.

repost: subqueries

Hello, on 04.08. I have asked a question and have not got any answer. It is important to me, so I will try to reformulate. Any help will be appreciated, for example a piece of code or an explanation how to use the method Criteria.addIn(String attributeName, Query subQuery) for something that can

Re: Compound Primary Key foreign key references

Dan -- Are you asking this question because you've tried this configuration and it doesn't work, or are you just confused as to how OJB will handle this situation? If the former, then please provide more info regarding the problems you're having. If the latter, then here's my explanation...

Antwort: Re: How to avoid 'RemovalAwareCollection' in 1:N mappings

Hi Jose, Using a link table and a programatically controlled M:N relation seems a reasonable approach. I'll try this out. Thanks for the tip. Gerhard Grosse <[EMAIL PROTECTED]> 18.08.2003 14:39 Bitte antworten an "OJB Users List" An: <[EMAIL PROTECTED]> Kopie: <[EMA

Antwort: RE: How to avoid 'RemovalAwareCollection' in 1:N mappings

Hi Olli, Thanks for the tip. The collection-class attribute indeed lets me specify the ManagableCollection implementation to use. After checking this out, however, it seems I only have the choice between (a) a RemovalAwareCollection, which will delete the removed child objects, or (b) a Managa

Compound Primary Key foreign key references

All, From what I can tell, the repository.dtd is not sufficient to uniquely reference an object with a compound primary key. I think I must be missing something. In the contrived example below the foreign keys used to reference class B are keyA and keyB. Unfortunately, the names of keyA and

Collection Problem

Hello! I discovered a problem with RC4 (RC3) concerning the Collection-Mapping. If the name of the primary key member variable in both classes is exactly the same, then the save procedure skips same ids. eg.: Status 1---n Person If you add a new status with a collection of corresponding persons,

Re: Problem with 1:m relation (ODMG, DList)

[EMAIL PROTECTED] wrote: Ok, I´ve just to rewrite all code with PB api, using Vector and RemovalAwareCollection and it works Try to use the ODMG instead of the PB API now. That worked for me, too. But I had problems using HashSet for collections (see previous mail "Collection problem" from 07.

Re: How to avoid 'RemovalAwareCollection' in 1:N mappings

Hi Gerhard It depens which is the relation 1:n. For example, invoice/lines_invoice, if an invoice is delete, its lines child must be deleted too. I´ve used the default collection (RemovalAwareCollection) in that relation (1:N) In other relation (person and role) I´ve used M:N relation, because a

Re: Problem with 1:m relation (ODMG, DList)

Ok, I´ve just to rewrite all code with PB api, using Vector and RemovalAwareCollection and it works But, why do not DList and ODMW work? I´ve seen DListImplementatio source code and I don´t recongnize any piece of code to call ODMG (PB) api.. jose Galiana > [EMAIL PROTECTED] wrote: > >>Hi, >

RE: How to avoid 'RemovalAwareCollection' in 1:N mappings

Hello Gerhard, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > the parent object to hold the child objects. Now it seems > that OJB always > assigns a RemovalAwareCollection to my collection attributes. > How can I > avoid this? add attribute collection-c

Mysql unit test questions

Hi, I've compiled OJB with bin\build.bat jar under windows and the unit tests run fine. Then as the next step I modified the build.properties and mysql.profile to point to my mysql server (the latest stable version) and ran the unit tests again, this is what I get: junit-no-compile-no-prepar

How to avoid 'RemovalAwareCollection' in 1:N mappings

Hi all, I can't seem to find a way to control how child objects are treated when removed from the collection of a parent object in a 1:N mapping. By default OJB (PB API) seems to delete the child object, regardless of the auto-upated/delete setting in repository.xml, but there must be a way to

Re: Problem with 1:m relation (ODMG, DList)

[EMAIL PROTECTED] wrote: Hi, I´ve must be really stupid but, after read tutorials, eMails, source code... I´ve not be able to run my 1:m code. Two classes A and B, with A <--- B relation (1:m) public class A { private int id; private DList listB; private String name; public void A() {