dev@glassfish.java.net

[Fwd: persistence Digest 24 Oct 2005 10:09:53 -0000 Issue 4]

From: Carla Mott <Carla.Mott_at_Sun.COM>
Date: Mon, 24 Oct 2005 17:44:38 -0700

-- 
Carla Mott
Sun Microsystems		
carla.mott_at_sun.com

attached mail follows:



Content-type: text/plain; charset=us-ascii
MIME-Version: 1.0


persistence Digest 24 Oct 2005 10:09:53 -0000 Issue 4

Topics (messages 5 through 9):

Re: persistence-api changes for new packaging proposal]
        5 by: Marina Vatkina
        9 by: Sanjeeb Kumar Sahoo

Re: Primary Key generation type IDENTITY
        6 by: Mitesh Meswani

Re: EJBQL parser update supporting TRIM
        7 by: Michael Bouschen

packaging withour .par
        8 by: Sanjeeb Kumar Sahoo

Administrivia:

To subscribe to the digest, e-mail:
        persistence-digest-subscribe_at_glassfish.dev.java.net

To unsubscribe from the digest, e-mail:
        persistence-digest-unsubscribe_at_glassfish.dev.java.net

To post to the list, e-mail:
        persistence_at_glassfish.dev.java.net


----------------------------------------------------------------------


Content-type: message/rfc822
MIME-Version: 1.0

Date: Thu, 20 Oct 2005 13:30:09 -0700
From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Subject: Re: [Fwd: Re: persistence-api changes for new packaging proposal]
To: Mike Keith <michael.keith_at_oracle.com>
Cc: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>,
 "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>,
 "ejb3-toplink_at_Sun.COM" <ejb3-toplink_at_Sun.COM>,
 "ejb3-toplink_ww_at_oracle.com" <ejb3-toplink_ww_at_oracle.com>
Message-id: <4357FE51.E9F4FA41_at_sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-15
Content-transfer-encoding: 7BIT

Mike,

The current spec proposal says (6.2.1 persistence.xml file):
"The persistence element consists of one or more persistence-unit elements."

What are the minimum requirements for persistence.xml?

thanks,
-marina

Mike Keith wrote:

> If a persistence-unit is specified then its name must be present.
> However, there is no requirement that the file contain one or more
> persistence-units.
>
> > -----Original Message-----
> > From: Sanjeeb Kumar Sahoo [mailto:Sanjeeb.Sahoo_at_Sun.COM]
> > Sent: Thursday, October 20, 2005 3:41 PM
> > To: Mike Keith
> > Cc: persistence_at_glassfish.dev.java.net; ejb3-toplink_at_Sun.COM;
> > ejb3-toplink_ww_at_oracle.com
> > Subject: Re: [Fwd: Re: persistence-api changes for new packaging
> > proposal]
> >
> >
> > Hi Mike,
> > Thanks for sending that schema. One minor comment:
> > Since name of a persistence-unit is no more optional, should
> > minOccurs
> > be 1 for persistence-unit?
> >
> > Thanks,
> > Sahoo
> >
> > Mike Keith wrote:
> >
> > >Sahoo, the latest updated persistence.xsd is attached.
> > >
> > >-Mike
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Sanjeeb Kumar Sahoo [mailto:Sanjeeb.Sahoo_at_Sun.COM]
> > >>Sent: Thursday, October 20, 2005 2:08 PM
> > >>To: persistence_at_glassfish.dev.java.net; ejb3-toplink_at_sun.com;
> > >>ejb3-toplink_ww_at_oracle.com
> > >>Subject: [Fwd: Re: persistence-api changes for new
> > packaging proposal]
> > >>
> > >>
> > >>Hi Team,
> > >> This is my plans for making changes in glassfish to the latest
> > >>packaging changes:
> > >>
> > >>1) I will use the latest proposal (the one sent by Linda
> > yesterday). I
> > >>will update persistence.xsd so that CTS tests can be
> > migrated from par
> > >>to jar as well as to new schema at the same time.
> > >>
> > >>2) Not all features from the new packaging spec will be
> > >>supported in the
> > >>initial check in. We will support the persistence unit to be part of
> > >>ejb-jar (stand alone as well as embedded), embedded war and embedded
> > >>library jar. The rest will be implemented subsequently.
> > >>
> > >>3) To minimize the amount of changes in one check in, we will
> > >>not update
> > >>the javax.persistence.spi interfaces in the first check in.
> > >>So to start
> > >>with we don't have to change the part of TopLink Essential that runs
> > >>inside container. All the supported features would work
> > fine. Once the
> > >>first phase of container changes are made, in the second phase both
> > >>container and TopLink Essential will be modified to use the new SPI.
> > >>I hope to check in the first set of changes by Monday (subject to
> > >>getting review comments from all reviewers).
> > >>The second phase of changes would include update to the SPIs.
> > >>This will
> > >>be done mid next week (*Tom, please confirm, whether this is
> > >>OK with you
> > >>or not*). This will be transparent to users.
> > >>
> > >>Thanks,
> > >>Sahoo
> > >>
> > >>
> > >>
> > >>
> >
> >



Content-type: message/rfc822
MIME-Version: 1.0

Date: Mon, 24 Oct 2005 13:52:42 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: Re: [Fwd: Re: persistence-api changes for new packaging proposal]
To: Tom Ware <tom.ware_at_oracle.com>
Cc: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Message-id: <435C99D2.5040801_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Hi Tom,
Tom Ware wrote:

> Sahoo,
>
> Here is my plan.
>
> I will implement a TopLink version that will handle both
> PersistenceInfo (the old class) and PersistenceUnitInfo (the new
> class). That way we can do a more seamless transition.
>
> I am attaching my version of PersistenceUnitInfo(cut and pasted from
> the spec) and one class it is dependant on. I believe it can be
> checked at in any time.
>
I have checked them in this morning after adding CDDL headers.

> After it is checked in, we can do the TopLink part of the work in 4
> phases.
>
> 1. Check in the TopLink version that implements both versions

I have asked Shelly to update CTS to new spec and run one round of CTS.
That way we would know if there was any regression in packaging changes
that I had committed. After that you can do this change. What do you
suggest?

> 2. Check in the Glassfish version that uses the new TopLink
> implementation

I have the changes in my local workspace. I can check them in after you
make change #1.

> 3. Remove the dependance on the old version from TopLink
> 4. Delete the PersistenceInfo class.

#3 & #4 can be done after #2 either by you or me.

Thanks,
Sahoo

>
> Let me know what you think,
> Tom
>
> Sanjeeb Kumar Sahoo wrote:
>
>> Hi Team,
>> This is my plans for making changes in glassfish to the latest
>> packaging changes:
>>
>> 1) I will use the latest proposal (the one sent by Linda yesterday).
>> I will update persistence.xsd so that CTS tests can be migrated from
>> par to jar as well as to new schema at the same time.
>>
>> 2) Not all features from the new packaging spec will be supported in
>> the initial check in. We will support the persistence unit to be part
>> of ejb-jar (stand alone as well as embedded), embedded war and
>> embedded library jar. The rest will be implemented subsequently.
>>
>> 3) To minimize the amount of changes in one check in, we will not
>> update the javax.persistence.spi interfaces in the first check in. So
>> to start with we don't have to change the part of TopLink Essential
>> that runs inside container. All the supported features would work
>> fine. Once the first phase of container changes are made, in the
>> second phase both container and TopLink Essential will be modified to
>> use the new SPI.
>> I hope to check in the first set of changes by Monday (subject to
>> getting review comments from all reviewers).
>> The second phase of changes would include update to the SPIs. This
>> will be done mid next week (*Tom, please confirm, whether this is OK
>> with you or not*). This will be transparent to users.
>>
>> Thanks,
>> Sahoo
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: persistence-api changes for new packaging proposal
>> From:
>> Tom Ware <tom.ware_at_oracle.com>
>> Date:
>> Thu, 20 Oct 2005 13:25:48 -0400
>> To:
>> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>>
>> To:
>> Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
>>
>>
>>
>>
>> Sanjeeb Kumar Sahoo wrote:
>>
>>> Tom Ware wrote:
>>>
>>>> What do you mean by "the latest proposal"? Are you referring to
>>>> the version of the proposal you sent me (dated 9/12/05)?
>>>>
>>> No. There was a new proposal sent out yesterday by Linda and Mike.
>>> Have you not seen it?
>>>
>> Ok, I'll use that one.
>>
>>>> As I mentioned in my earlier email, the changes we have to make in
>>>> order to be functional on the application server are minimal.
>>>> Essentially, we just need to update our implementation of
>>>> PersistenceInfo so that it will compile. You mentioned yesterday
>>>> that you thought we could come initial work without the change to
>>>> javax.persistence.PersitenceInfo.
>>>
>>>
>>>
>>>
>>> I would prefer this way as opposed to changing both container and
>>> provider at the same time. What do you say?
>>
>>
>>
>>
>> That's fine with me.
>>
>>>
>>> Thanks,
>>> Sahoo
>>>
>>>>
>>>> -Tom
>>>>
>>>> Sanjeeb Kumar Sahoo wrote:
>>>>
>>>>> Hi Tom,
>>>>> First we need to agree on the persistence-api changes. The latest
>>>>> proposal now contains the schema and changed APIs. Do you plan to
>>>>> use them or do you have some other version? In any case, if you
>>>>> have the .java files and .xsd files, please send them to me.
>>>>>
>>>>> Thanks,
>>>>> Sahoo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>




Content-type: message/rfc822
MIME-Version: 1.0

Date: Thu, 20 Oct 2005 14:18:09 -0700
From: Mitesh Meswani <mitesh.meswani_at_Sun.COM>
Subject: Re: Primary Key generation type IDENTITY
To: Mike Keith <michael.keith_at_oracle.com>
Cc: Peter Krogh <peter.krogh_at_oracle.com>, Ming Zhang <ming.zhang_at_Sun.COM>,
 "ejb3-toplink-ext_at_Sun.COM" <ejb3-toplink-ext_at_Sun.COM>,
 "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Message-id: <43580991.7010504_at_sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Mike,
Thanks for correcting. My original question below was not correct.

Peter,
The correct question this time. Does Toplink support
GeneratorType.IDENTITY? What is the expected DDL for the target table
for various dbs?

Thanks,
Mitesh

Mike Keith wrote:

>Sounds like there is some confusion around this issue. Maybe I can help.
>
>- There is no IdentityGenerator in the spec. When the generation
>type is set to IDENTITY then it means that an IDENTITY column, such
>as is available in SQL Server and Sybase, is used. This is different
>from SEQUENCE, which requires a database sequence be set up.
>
>- When IDENTITY is used then the table must be generated to have
>an IDENTITY column in it (e.g. in SQL Server it might look something
>like:
>
>CREATE TABLE Employee (
> id int IDENTITY(10,2),
> name varchar(50)
>)
>
>The identifier attribute must be mapped to the identity column.
>
>-Mike
>
>
>
>>-----Original Message-----
>>From: Mitesh Meswani [mailto:mitesh.meswani_at_Sun.COM]
>>Sent: Thursday, October 20, 2005 1:56 PM
>>To: Peter Krogh
>>Cc: Ming Zhang; ejb3-toplink-ext_at_Sun.COM;
>>persistence_at_glassfish.dev.java.net
>>Subject: Re: Primary Key generation type IDENTITY
>>
>>
>>Hi Peter,
>>
>>I will try to clarify the question on Ming's behalf:
>>Does toplink support IdentityGenerator for generated pk
>>values. If yes,
>>what is the expected DDL for running against various dbs.
>>
>>Thanks,
>>Mitesh
>>
>>Peter Krogh wrote:
>>
>>
>>
>>>I am not sure that I fully understand your questions, but
>>>
>>>
>>let me give
>>
>>
>>>them a shot.
>>>
>>>1. Are the sequence name "SEQ_GEN_SEQUENCE" and its
>>>
>>>
>>increment/initial
>>
>>
>>>values changeable for IDENTITY type PK?
>>>I think that this is what the SeqeunceGenerator annotation is for.
>>>
>>>2. Is there an IdentityGenerator annotation similar to
>>>@SequenceGenerator? What's the usage? In case of @SequenceGenerator,
>>>the above values can be set in its elements. For example:
>>> @SequenceGenerator(name="mySequenceGenerator", sequenceName =
>>>"SEQ_NAME", initialValue=1, allocationSize=1)
>>>
>>>Again, I believe that the correct one to use is the
>>>SeqeunceGenerator. The table based sequencing is called
>>>
>>>
>>TableGenerator.
>>
>>
>>>The error that you are getting is because the allocation size is set
>>>to 50. You must either set the increment by on your sequence to 50,
>>>or change the allocation size using SequenceGenerator like you
>>>indicated above.
>>>
>>> -----Original Message-----
>>>*From:* Ming Zhang [mailto:ming.zhang_at_Sun.COM]
>>>*Sent:* Thursday, October 20, 2005 12:38 PM
>>>*To:* Peter Krogh
>>>*Cc:* ejb3-toplink-ext_at_Sun.COM
>>>*Subject:* Re: Primary Key generation type IDENTITY
>>>
>>> I an using DDL. Added the "create sequence" in it:
>>> create table datatypes(ID INTEGER, shortData smallint, longData
>>> number, floatData real,
>>> sqldatedata date, utildatedata date, timeStampData timestamp(9),
>>> integerData integer,
>>> byteData number, booleanData number, characterData char(100),
>>> CONSTRAINT DATATYPES_PK PRIMARY KEY (ID));
>>>
>>> create sequence SEQ_GEN_SEQUENCE START WITH 1 INCREMENT BY 1;
>>>
>>> Now I got "increment does not match its pre-allocation size":
>>> Caused by: Exception [TOPLINK-7027] (Oracle TopLink Essentials -
>>> 10g release 4 (10.1.4.0.0) (Build 051010Dev)):
>>> oracle.toplink.essentials.exceptions.ValidationException
>>> Exception Description: The sequence named [SEQ_GEN_SEQUENCE] is
>>> setup incorrectly. Its increment does not match its
>>> pre-allocation size.
>>> at
>>>
>>>
>>>
>>oracle.toplink.essentials.exceptions.ValidationException.seque
>>nceSetupIncorrectly(ValidationException.java:1200)
>>
>>
>>> at
>>>
>>>
>>>
>>oracle.toplink.essentials.sequencing.StandardSequence.createVe
>>ctor(StandardSequence.java:146)
>>
>>
>>> ...
>>>
>>> But still have following questions:
>>> 1. Are the sequence name "SEQ_GEN_SEQUENCE" and its
>>> increment/initial values changeable for IDENTITY type PK?
>>> 2. Is there an IdentityGenerator annotation similar to
>>> @SequenceGenerator? What's the usage? In case of
>>> @SequenceGenerator, the above values can be set in its elements.
>>> For example:
>>> @SequenceGenerator(name="mySequenceGenerator", sequenceName =
>>> "SEQ_NAME", initialValue=1, allocationSize=1)
>>>
>>> Thanks,
>>> Ming
>>>
>>>
>>> Peter Krogh wrote:
>>>
>>>
>>>
>>>> It appears that this sequence is not created on the DB.
>>>>
>>>> How are you creating this? Using the DDL generation?
>>>>
>>>>
>>Manually?
>>
>>
>>>> Check the DB and see if that sequence is created
>>>>
>>>> -----Original Message-----
>>>> *From:* Ming Zhang [mailto:ming.zhang_at_Sun.COM]
>>>> *Sent:* Wednesday, October 19, 2005 8:54 PM
>>>> *To:* ejb3-toplink-ext_at_Sun.COM
>>>> *Subject:* Primary Key generation type IDENTITY
>>>>
>>>> Hello TopLink experts,
>>>>
>>>> I have some general questions regarding the IDENTITY PK
>>>> generation type. How is the ID annotated in this
>>>>
>>>>
>>case and is
>>
>>
>>>> there a IdentityGenerator annotation similar to
>>>> @SequenceGenerator annotation? What's the specific
>>>>
>>>>
>>usage? How
>>
>>
>>>> do we handle these in DDL?
>>>>
>>>> I tried @Id(generate = GeneratorType.IDENTITY) in
>>>>
>>>>
>>my apps and
>>
>>
>>>> was able to compile deploy. But got following exception
>>>> during runtime:
>>>> Caused by: Exception [TOPLINK-4002] (Oracle TopLink
>>>> Essentials - 10g release 4 (10.1.4.0.0) (Build 051010Dev)):
>>>> oracle.toplink.essentials.exceptions.DatabaseException
>>>> Internal Exception: java.sql.SQLException:
>>>>
>>>>
>>[sunm][Oracle JDBC
>>
>>
>>>> Driver][Oracle]ORA-02289: *sequence does not exist*
>>>> Error Code: 2289
>>>> Call:SELECT SEQ_GEN_SEQUENCE.NEXTVAL FROM DUAL
>>>> Query:ValueReadQuery()
>>>> at
>>>>
>>>>
>>>>
>>oracle.toplink.essentials.exceptions.DatabaseException.sqlExce
>>ption(DatabaseException.java:310)
>>
>>
>>>> at
>>>>
>>>>
>>>>
>>oracle.toplink.essentials.internal.databaseaccess.DatabaseAcce
>>ssor.basicExecuteCall(DatabaseAccessor.java:550)
>>
>>
>>>> at
>>>>
>>>>
>>>>
>>oracle.toplink.essentials.internal.databaseaccess.DatabaseAcce
>>ssor.executeCall(DatabaseAccessor.java:436)
>>
>>
>>>> Thanks,
>>>> Ming
>>>>
>>>>
>>>>
>>>> 6f4mWKmVZd/5GiAuNBf0Rw)--
>>>>
>>>>
>>>>
>>
>>
>
>
>
>


Content-type: message/rfc822
MIME-Version: 1.0

Date: Fri, 21 Oct 2005 19:52:04 +0200
From: Michael Bouschen <Michael.Bouschen_at_Sun.COM>
Subject: Re: EJBQL parser update supporting TRIM
To: Tom Ware <tom.ware_at_oracle.com>
Cc: persistence_at_glassfish.dev.java.net
Message-id: <43592AC4.6050305_at_sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Hi Tom,

Thangs for looking into this. I can check it in. I think it makes sense
to have this a separate check in from packaging component changes.

Regards Michael

> Michael,
>
> Looks good. Should I check it into glassfish, or do you want to? If
> I check it in, it will probably go in when the packaging component
> goes in.
>
> -Tom
>
>
> Michael Bouschen wrote:
>
>> Hi Tom,
>>
>> attached you find a new update of the EJBQL parser implementation
>> (EJBQL-Trim-051019.jar). Comments are welcome.
>>
>> It adds support for the string function TRIM to the EJBQL parser in
>> entity-persistence. This version throws an exception if the TRIM
>> function defines a trim character for a none TRAILING trim
>> specification. I will remove this as soon as the expression framework
>> support this feature.
>>
>> Regards Michael
>>
>>
>>
>>
>>



Content-type: message/rfc822
MIME-Version: 1.0

Date: Mon, 24 Oct 2005 13:48:23 +0530
From: Sanjeeb Kumar Sahoo <Sanjeeb.Sahoo_at_Sun.COM>
Subject: packaging withour .par
To: "Shelly (Donna) McGowan" <Shelly.McGowan_at_Sun.COM>
Cc: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Message-id: <435C98CF.8060307_at_Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

Hi Shelly,
   glassfish now supports packaging of JSR 220 entity beans in jar/war
files. Would you mind upgrading CTS tests to use the new packaging
format? At this point, I would suggest making just the necessary
changes, i.e. update the persistence.xml to new schema and change file
extension from par to jar. Let's not bundle the driver in a war file to
start with, let them be in an ejb-jar. Is it possible to test these
changes first? Once this works, we will change TopLink Essentials to use
the new SPIs. We are not changing TopLink Essentials at this point
because we want to do these changes in steps.

Thanks,
Sahoo