persistence@glassfish.java.net

Re: AS9.0 and java2db feature

From: Pavel Buzek <Pavel.Buzek_at_Sun.COM>
Date: Mon, 21 Nov 2005 23:56:09 -0500

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.
>
>