You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-user@db.apache.org by Joachim Draeger <jd...@joachim-draeger.de> on 2006/10/04 22:49:39 UTC
getting primary, auto-generated, key with derby and torque-3.2
Hi!
As I could figure out from different sources this doesn't work at all at
the moment. Or am I missing something?
So I had to override doInsert in the Peer class and remove
obj.setPrimaryKey(doInsert(buildCriteria(obj))) and just use
doInsert(buildCriteria(obj)) to avoid NPEs.
I did a quick look into SVN and it look likes this has been fixed in
trunk.
What would you recommend to use derby now?
1. use a custom build of torque that supports derby
2. workaround by using a second table for key management
I wouldn't like random keys...
Unfortunately there are no public snapshot-builds that could be used by
other projects. But I just heard rumors you're planning torque
3.2.1. :-) I really would appreciate full derby support!
greetings,
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
Re: getting primary, auto-generated, key with derby and torque-3.2
Posted by Thomas Fischer <tf...@apache.org>.
Hi Joachim,
Derby support was still in the alpha stage when 3.2 was released. In the
meantime, I believe it is fully working in svn. I'd recommend a svn pull
of the sources from svn trunk and a custom build. As far as I know, there
are no large issues open at the moment which have not been in 3.2 also.
The Torque team hopes to create a first release candidate of Torque 3.2.1
in a few weeks. It would be great if any issues regarding derby support
would be raised before that time.
Thomas
On Wed, 4 Oct 2006, Joachim Draeger wrote:
>
> Hi!
>
> As I could figure out from different sources this doesn't work at all at
> the moment. Or am I missing something?
> So I had to override doInsert in the Peer class and remove
> obj.setPrimaryKey(doInsert(buildCriteria(obj))) and just use
> doInsert(buildCriteria(obj)) to avoid NPEs.
> I did a quick look into SVN and it look likes this has been fixed in
> trunk.
>
> What would you recommend to use derby now?
> 1. use a custom build of torque that supports derby
> 2. workaround by using a second table for key management
> I wouldn't like random keys...
>
> Unfortunately there are no public snapshot-builds that could be used by
> other projects. But I just heard rumors you're planning torque
> 3.2.1. :-) I really would appreciate full derby support!
>
> greetings,
>
> Joachim
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org