Dain,
I thought a little more and understood that the Castor KeyGenerators can't be
used standalone. They should be adapted to JBoss CMP 2.0, but we can use the
existing codebase. The reason why not all of the key generators can be used
standalone is that some them need SELECT with lock (SELECT FOR UPDATE) and
they use some other Castor classes to get the query with database-specific
syntax, while JBoss CMP 2.0 has it's own means for that, if I'm not mistaken.
I propose that you think about the best way of plugging key generators in,
then I'll adapt the Castor code.
Please read http://castor.exolab.org/key-generator.html to get a general idea
about them and to see the list of supported databases and algorithms.
Also see the KeyGenerator interface below, please read the comments.
Oleg
/**
* Interface for a key generator. The key generator is used for
* producing identities for objects before they are created in the
* database.
* <p>
* All the key generators belonging to the same database share the
* same non-transactional connection to the database.
* <p>
* The key generator is configured from the mapping file using
* Bean-like accessor methods.
*
* @author <a href="[EMAIL PROTECTED]">Assaf Arkin</a>
* @author <a href="[EMAIL PROTECTED]">Oleg Nitz</a>
* @version $Revision: 1.7 $ $Date: 2000/12/17 15:40:44 $
*/
public interface KeyGenerator
{
/**
* For the key generators of BEFORE_INSERT style {@link #generateKey}
* is called before INSERT.
* {@link #patchSQL} may be used but usually doesn't.
*/
public static final byte BEFORE_INSERT = -1;
/**
* For the key generators of DURING_INSERT style {@link #generateKey}
* is never called, all work is done by {@link #patchSQL}.
*/
public static final byte DURING_INSERT = 0;
/**
* For the key generators of AFTER_INSERT style {@link #generateKey}
* is called after INSERT.
* {@link #patchSQL} may be used but usually doesn't.
*/
public static final byte AFTER_INSERT = 1;
/**
* Generate a new key for the specified table. This method is
* called when a new object is about to be created. In some
* environments the name of the owner of the object is known,
* e.g. the principal in a J2EE server.
* This method is never called for DURING_INSERT key generators.
*
* @param conn An open connection within the given transaction
* @param tableName The table name
* @param primKeyName The primary key name
* @param props A temporary replacement for Principal object
* @return A new key
* @throws PersistenceException An error occured talking to persistent
* storage
*/
public Object generateKey( Connection conn, String tableName,
String primKeyName, Properties props )
throws PersistenceException;
/**
* Style of the key generator: BEFORE_INSERT, DURING_INSERT or
AFTER_INSERT.
*/
public byte getStyle();
/**
* Gives a possibility to patch the Castor-generated SQL statement
* for INSERT (indended mainly for DURING_INSERT style of key generators,
* other key generators usually simply return the passed parameter).
* The original statement contains primary key column on the first place
* for BEFORE_INSERT style and doesn't contain it for the other styles.
* This method is called once for each class and must return String
* with '?' that can be passed to CallableStatement (for DURING_INSERT
* style) or to PreparedStatement (for the others).
* Then for each record being created actual field values are
substituted,
* starting from the primary key value for BEFORE_INSERT style, of
starting
* from the first of other fields for the other styles.
* The DURING_INSERT key generator must add one OUT parameter to the end
* of the parameter list, which will return the generated identity.
* For example, ReturningKeyGenerator for Oracle8i transforms
* "INSERT INTO tbl (pk, fld1, ...,fldN) VALUES (?,?...,?)" to
* "INSERT INTO tbl (pk, fld1, ...) VALUES (seq.nextval,?....,?)
* RETURNING pk INTO ?".
* DURING_INSERT key generator also may be implemented as a stored
procedure.
* @param insert Castor-generated INSERT statement
* @param primKeyName The primary key name
*/
public String patchSQL( String insert, String primKeyName )
throws MappingException;
/**
* Is key generated in the same connection as INSERT?
* For DURING_INSERT style this method is never called.
*/
public boolean isInSameConnection(); // this one should be dropped
}
Dain Sundstrom wrote:
> Cool. I think we should look at using this post beta.
> -dain
>> -----Original Message-----
>> From: Oleg Nitz [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, January 14, 2002 10:23 AM
>> To: Dain Sundstrom
>> Subject: Re: [JBoss-dev] Autogenerated primary keys etc
>>
>>
>> Dain Sundstrom wrote:
>> > If you want to write the code for the most popular data
>> bases, I'll attempt
>> > to write a plugable engine for it.
>> The code is already written in Castor and can be easily reused.
>> There is KeyGenerator interface that can be used independently from
>> other CastorJDO code.
>> And the castor.jar is bundled with JBoss 3.0, isn't it?
>> And Castor KeyGenerators are well tested, don't reinvent the wheel :)
>>
>> Oleg
>>
>> > -dain
>>
>> >> -----Original Message-----
>> >> From: Lennart Petersson [mailto:[EMAIL PROTECTED]]
>> >> Sent: Monday, January 14, 2002 3:18 AM
>> >> To: [EMAIL PROTECTED]
>> >> Subject: Re: RE: [JBoss-dev] Autogenerated primary keys etc
>> >>
>> >>
>> >> Ok, what i was looking for to hear about was the ability to
>> >> support different databases
>> >> auto-generated columns. I see the problem with it, just
>> >> wanted to check if anyone had
>> >> give it a try for some of the most popular databases...
>> >>
>> >> Guess i will wait for JDBC 3.0 :)
>> >> /Lennart
>> >>
>> >> Den 2002-01-11 19:23:44 skrev Dain Sundstrom <[EMAIL PROTECTED]>:
>> >>
>> >> >Here is the scoop.
>> >> >
>> >> >Last I checked Oleg was working on this for EJB 2.0, but I
>> >> have trouble
>> >> >contacting him (our email servers don't like each other).
>> >> >
>> >> >The way it will be implemented is with a lookup in JNDI that
>> >> returns an
>> >> >object that implements some yet to be defined AutoNumber
>> >> interface. I think
>> >> >the initial revision uses a sequence table.
>> >> >
>> >> >I don't think we will be able to support auto-generated
>> >> columns, as this
>> >> >requires special sql in the insert statement or special
>> >> handling of the
>> >> >prepared statement object. When we start seeing JDBC 3.0
>> >> drivers, which
>> >> >support auto-generated columns, we will be able to add
>> >> generic support.
>> >> >
>> >> >To make a long story short, it should be in JBoss 3.0 final.
>> >> >
>> >> >-dain
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Jboss-development mailing list
>> >> [EMAIL PROTECTED]
>> >> https://lists.sourceforge.net/lists/listinfo/jboss-development
>> >>
>>
>> > _______________________________________________
>> > Jboss-development mailing list
>> > [EMAIL PROTECTED]
>> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
>>
>>
>> _______________________________________________
>> Jboss-development mailing list
>> [EMAIL PROTECTED]
>> https://lists.sourceforge.net/lists/listinfo/jboss-development
>>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
