I'm unsure of where to put this code. 1) TranQL doesn't have modules like Geronimo and OpenEJB, which makes it harder to create the two self-contained modules (pkgen and pkgen-builder, I'm thinking) that would be needed for this.
2) It doesn't make sense to put this stuff in OpenEJB, if you seriously think it will be used from web apps 3) I'm happy to put it in Geronimo, but I'm not sure TranQL wants to depend on Geronimo Aaron On Fri, 17 Jun 2005, Jeremy Boynes wrote: > Aaron Mulder wrote: > <snip/> > > So to get around to my point, I'd like to propose an alternative: > > > > - We make the key generator into a "key generator factory" -- that is, > > something that knows how to produce a certain type of key generator (based > > on sequence or table or auto increment or whatever), but is not itself a > > generator and does not have EJB-specific configuration attached. > > > > I would suggest that instead of this being a runtime component, the > factory is actually built into the builder subsystem (like the naming > and security stuff is). There would be a "key-generation" XML-Schema > that users would use to define what one looked like which would be used > by the builder to generate the actual GBean. > > This would be then be re-usable outside just the EJB file e.g. for web > applications that needed to generate keys too. > > The primary use for this is to define a "shared" generator that can be > referenced by many components. > > > - We provide some additional XML elements where the EJB defines a key > > generator -- to let you provide configuration data there. It would also > > let you refer to an arbitrary GBean like now, to handle custom generators. > > > > I agree we should replace the generic GBean reference (or at least > deprecate it). I think we need both of two alternatives: > > 1) an element that refers to a "shared" generator defined above > > 2) elements that define the generation technique to use in conjunction > with creation of this individual entity. This could be openejb > specific or could be part of the "key-generation" XML-Schema - I tend > to prefer the latter as we can then keep all keygen like stuff > together > > > - In our code, when we process an EJB with a reference to a generator, we > > construct some kind of properties object, pop in the data source for the > > EJB, and add any properties specified in the new config elements. We pass > > the properties object to the named generator factory, and it returns a > > configured generator for the EJB to use. So the factory would have a > > method like "public KeyGenerator createGenerator(Hashtable properties)". > > > > I don't think you need this if you have the XML defined for producing > generator instances > > > - We define our 3 known generator factories in the standard server plans, > > so they'll have known/expected GBean Names and types > > > > With the approach above these would be replaced by the builder; if they > needed to be added anywhere it would be to the deployer plans but not > the runtime ones. > > <snip/> > > An example of this would be: > > <ejb-jar> > <enterprise-beans> > <entity> > <ejb-name>fooEJB</ejb-name> > <key-generator>foo</key-generator> > </entity> > <entity> > <ejb-name>barEJB</ejb-name> > <generated-identity> > <identity-column>BAR_ID</identity-column> > </generated-identity> > </entity> > </enterprise-beans> > <key-generators xmlns="http://tranql.org/xsd/keygen/1.0";> > <database-sequence name="foo"> > <sql>SELECT SOME_SEQUENCE.NEXTVAL FROM DUAL</sql> > <block-size>10</block-size> > </database-sequence> > </key-generators> > </ejb-jar> > > Where for "foo" we pre-fetch the identity from the shared sequence and > for "bar" we are extracting it after the insert. This plan is providing > the definition for the "foo" generator but it could actually be > elsewhere (e.g. in the EAR plan or in a separate one). > > We should be able to keep the stuff in OpenEJB fairly generic and > delegate all the db-specific stuff to TranQL and the associated dialect. > > -- > Jeremy >
