Hi Andy,

for testing reasons I changed the type of a PK field from java.util.Date
to java.sql.Date. Running the JPOX enhancer I noticed that the declaring
pc class was not enhanced. After I changed the field type back to
java.util.Date, the pc class was enhanced properly. Does JPOX support
java.sql.Date for PK fields?

You can easily reproduce the problem patching class
"org.apache.jdo.tck.pc.singlefieldidentity.PCPointSingleFieldDate": Just
change the import statement "import java.util.Date;" to "import
java.sql.Date;" and run the JPOX enhancer for application identity:

maven -Djdo.tck.identitytypes=applicationidentity doEnhance.jdori

Regards,
Michael
--
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

[ Post a follow-up to this message ]

Hi Michael,

> for testing reasons I changed the type of a PK field from java.util.Date
> to java.sql.Date. Running the JPOX enhancer I noticed that the declaring
> pc class was not enhanced. After I changed the field type back to
> java.util.Date, the pc class was enhanced properly. Does JPOX support
> java.sql.Date for PK fields?

Don't see why not, but then I don't see somewhere where I'd want to ;-)

> You can easily reproduce the problem patching class
> "org.apache.jdo.tck.pc.singlefieldidentity.PCPointSingleFieldDate": Just
> change the import statement "import java.util.Date;" to "import
> java.sql.Date;" and run the JPOX enhancer for application identity:

Well if you do that you need to bear in mind that java.sql.Date is *not* by
default persistent (nor is it in the DFG), whereas java.util.Date is. In you
r
class you have no persistence-modifier="persistent" and so the field that yo
u
want to be PK is *not* actually persistent. That's likely the issue. If you
look in the log from the enhancer you'll probably find something


--
Andy

[ Post a follow-up to this message ]

Hi Andy,

> Hi Michael,
>
> 
>
>
> Don't see why not, but then I don't see somewhere where I'd want to ;-)
>
> 
>
>
> Well if you do that you need to bear in mind that java.sql.Date is *not* b
y
> default persistent (nor is it in the DFG), whereas java.util.Date is. In y
our
> class you have no persistence-modifier="persistent" and so the field that 
you
> want to be PK is *not* actually persistent. That's likely the issue. If yo
u
> look in the log from the enhancer you'll probably find something

I agree, fields of type java.sql.Date do not default to persistent,
where fields of type java.util.Date are persistent by default.

The field is marked as primary-key field and the persistence-modifier of
a primary-key field defaults to persistent. So we thought there is no
need to add persistence-modifier="persistent" to the field metadata,
when changing the type from util.Date to sql.Date.

Regards Michael


>
>


--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]

Hi Michael,

> I agree, fields of type java.sql.Date do not default to persistent,
> where fields of type java.util.Date are persistent by default.
>
> The field is marked as primary-key field and the persistence-modifier of
> a primary-key field defaults to persistent. So we thought there is no
> need to add persistence-modifier="persistent" to the field metadata,
> when changing the type from util.Date to sql.Date.

That's true.

Is java.sql.Date, Time, Timestamp a requirement of ObjectIdentity?
The JDO2 spec remains silent, which means that the impl can really decide fo
r
itself if it feels like supporting it. JDOImplHelper implies that it is only
for java.util.Date, java.util.Currency, java.util.Locale.

If you want to take this further, you should find any useful info in the
enhancer log (which is turned off with the TCK's current mode of operation
for some reason). Since I've got plenty to do right now, I consider this low
priority.

--
Andy

[ Post a follow-up to this message ]

Hi Andy,

> Hi Michael,
>
> 
>
>
> That's true.
>
> Is java.sql.Date, Time, Timestamp a requirement of ObjectIdentity?
> The JDO2 spec remains silent, which means that the impl can really decide 
for
> itself if it feels like supporting it. JDOImplHelper implies that it is on
ly
> for java.util.Date, java.util.Currency, java.util.Locale.

I think support for java.sql.Date, Time, Timestamp is not a requirement.
For a non SQL JDO implementation such support is less obvious.

>
> If you want to take this further, you should find any useful info in the
> enhancer log (which is turned off with the TCK's current mode of operation
> for some reason). Since I've got plenty to do right now, I consider this l
ow
> priority.
>

I agree, this is low priority. BTW, how do I turn on the enhancer log?

Regards Michael
--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]

> BTW, how do I turn on the enhancer log?

Hi Michael,

Add the following line to "project.properties"
jdo.enhancer.sysproperties = -Dlog4j.configuration=file:
${basedir}/test/conf/logging.properties

The log will be dumped into target/classes (or somewhere similar) IIRC

--
Andy

[ Post a follow-up to this message ]

Hi Andy,
 
>
>Hi Michael,
>
>Add the following line to "project.properties"
>jdo.enhancer.sysproperties = -Dlog4j.configuration=file:
>${basedir}/test/conf/logging.properties
>
>
Thanks for the info!

How about if I add this line to the project.properties and comment it
out? Then we just need to remove the comment in order to get more info
from the enhancer.

>The log will be dumped into target/classes (or somewhere similar) IIRC
>
>
>
I found it under target/enhanced/jdori/applicationidentity. This
directory is passed as argument to the -d option when the enhancer is
called for applicationidentity.

Regards Michael

--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

[ Post a follow-up to this message ]