Pavel,
It's on our highest priority to-do list. But we need to make sure, both -
the runtime and java2db work on Derby, as the latter can't work without
the former.
In the meantime, if you can try it with some other database or with a
limited set of field types, it'll help us with making sure that there are
no other problems.
thanks,
-marina
Pavel Buzek wrote:
> Pramod,
>
> this is really cool! But does it work for the default database that is
> bundled with GlassFish with the default JDBC data source that is
> registered in GlassFish (Derby, jdbc/__default)?
>
> I tested this and I think that the scripts that are generated cannot be
> run on derby. From the examples in your post it looks like you are
> testing with oracle? (Just guessing, I see "create_ora.jdbc", etc.)
>
> My example:
>
> @Entity
> public class Foo {
> private int id;
> private String name;
> private String address;
> private Integer age;
> private Boolean smoker;
>
> @Id(generate = GeneratorType.AUTO)
> public int getId() {
> return id;
> }
> ...etc., get/set for each field
> }
>
> [#|2005-11-21T23:48:35.567-0500|WARNING|sun-appserver-pe9.0|javax.enterprise.resource.jdo.codegen.ejb|_ThreadID=18;_ThreadName=Thread-33;|JDO76609:
> Got SQLException executing statement "CREATE TABLE FOO (ID NUMBER(10)
> NOT NULL, ADDRESS VARCHAR2(255) NULL, AGE NUMBER(10) NULL, NAME
> VARCHAR2(255) NULL, SMOKER VARCHAR2(255) NULL, PRIMARY KEY (ID))":
> org.apache.derby.client.am.SqlException: Syntax error: Encountered "" at
> line 1, column 22.|#]
>
> "NUMBER(10)" is what causes error on Derby. Is there a way to change the
> generation of DDL so that it would work on Derby? Like a special
> parameter to choose a different syntax of DDL?
>
> Thanks,
> -pavel
>
> Pramod Gopinath wrote:
> > Hi
> >
> > I have checked in the changes for supporting java2db from within the
> > application server environment. I have attached a document that U could
> > use to start using this feature. As and when I update the document I
> > will keep U all posted.
> >
> > Thanks
> > Pramod Gopinath
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Support for Java2db in AS9.0
> >
> >
> > As of 11/21/2005
> >
> >
> > Currently we support java2db from within the application server
> > environment. When the out of container case is supported this document
> > would be updated to reflect it.
> >
> >
> > How to enable the java2db feature for a ejb 3.0 ear ?
> >
> > To enable java2db for an ejb 3.0 ear define the following properties for
> > a persistence unit descriptor in the persistence.xml.
> >
> > "ddl-generation" ::: with possible values of
> > "createtables"/"dropandcreate"/"none"
> >
> > "create-ddl-jdbc-file-name" ::: (optional): <name of the create ddl file>
> >
> > "drop-ddl-jdbc-file-name" ::: (optional): <name of the create ddl file>
> >
> > "application-location" (For within a container in the code this value
> > would be set to the app generated directory. This property would be used
> > for the out of container case to define the location where one would
> > want the jdbc ddl files to be stored.).
> >
> >
> > e.g. of a persistence.xml usage could be
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> >
> > <persistence xmlns="http://java.sun.com/xml/ns/persistence"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
> >
> > <persistence-unit name="em">
> >
> > <description>This is a test persistence.xml for java2db
> > support</description>
> >
> > <properties>
> >
> > <property name="ddl-generation" value="dropandcreate"/>
> >
> > <property name="create-ddl-jdbc-file-name" value="create_ora.jdbc"/>
> >
> > <property name="drop-ddl-jdbc-file-name" value="drop_ora.jdbc"/>
> >
> > </properties>
> >
> > </persistence-unit>
> >
> > </persistence>
> >
> >
> >
> > How to enable java2db feature w/o changing the ejb3.0 ear ?
> >
> > The easiest way to enable this feature w/o changing the application ear
> > is by using the asadmin cli commands :
> >
> > --createtables=true/false. Specified at deploy time to ensure that the
> > tables are created in the database.
> >
> > --dropandcreatetables=true/false. Specified at redeploy time to ensure
> > that the old tables are dropped and new ones created at redeploy time.
> >
> > --droptables=true/false. Specified at undeploy time to ensure that the
> > tables are dropped from the database.
> >
> >
> > These are the same commands that work with our application server for
> > cmp2.x beans. These options overwrite the setting of the properties that
> > might be defined in the persistence.xml.
> >
> >
> > example :
> >
> > 1.
> >
> > Command to deploy an ejb3.0 application that does not contain the
> > properties defined but still create the required tables in the
> > database :
> >
> > $S1AS_HOME/bin/asadmin deploy --retrieve . --user admin --password
> > adminadmin --host localhost --port 4848 --createtables=true --name
> > onetomany --force=true
> > /export/home/tools/ejb30_related/persistence-onetomanyApp.ear
> >
> > 2.
> >
> > Command to redeploy an ejb3.0 application that does not contain
> > the properties and ensure that the tables get recreated in the
> > database :
> >
> > $S1AS_HOME/bin/asadmin deploy --retrieve . --user admin --password
> > adminadmin --host localhost --port 4848 --dropandcreatetables=true
> > --name onetomany --force=true
> > /export/home/tools/ejb30_related/persistence-onetomanyApp.ear
> >
> > 3.
> >
> > Command to undeploy the ejb3.0 application that does not contain
> > the properties and ensure that the tables get dropped from the
> > database :
> >
> > $S1AS_HOME/bin/asadmin undeploy --user admin --password adminadmin
> > --host localhost --port 4848 --droptables=true onetomany
> >
> >
> >
> > How does the cli commands interact/affect the properties if they are
> > defined in persistence.xml ?
> >
> > The cli options (--createtables/--dropandcreatetables/--droptables) take
> > precedence over the properties in the persistence.xml.
> >
> >
> > Lets take an example to further explain this :
> >
> > The user has defined the following in their persistence.xml
> >
> > ddl-generation : dropandcreate
> >
> > and then when deploying the application has specified
> >
> > --createtables=false.
> >
> > We then create the jdbc ddl statements but not execute the ddl
> > statements against the database. But if the --createtables option is not
> > defined at the deploy time, we would create the jdbc ddl statements and
> > also execute the ddls against the database.
> >
> >
> >
> > What happens if the jdbc ddl file names are not specified in the
> > persistence.xml ?
> >
> > This situation is similar to the cmp2.x case and we end up create ddl
> > files with some default names. We try to create the name of the file by
> > prepending the application and/or module name followed by the
> > persistence unit name and then a static string of the form
> > "createDDL.jdbc" or "dropDDL.jdbc".
> >
> >
> > So you might see files with names like
> >
> >
> > default_em_dropDDL.jdbc and default_em_createDDL.jdbc
> >
> > OR
> >
> > realApp_war1_ejb_em1_dropDDL.jdbc and realApp_war1_ejb_em1_createDDL.jdbc
> >
> > (this is case where the persistence.xml is defined in a war file)
> >
> >
> >
> > Do all the asadmin command options for java2db defined for AS8.x work as
> > is with AS9.0 ?
> >
> > Not at this point of time. There are options like uniquetablenames and
> > dbvendorname that can be defined for AS8.x and are currently not
> > supported for AS9.0. These options might be supported in the future and
> > this document would be updated to reflect the same.
> >
> >