Sadly, I believe that a discussion of the properties permitted to
pass the TCK is found in the TCK configuration requirements, which I
believe is confidential and therefore out of bounds for this alias.
I hope to be corrected.
Craig
On Aug 15, 2006, at 2:20 PM, Michael Dick wrote:
> I think it would be better to pass the TCK without any properties that
> change behavior.
>
> Does anyone know if Sun has a guideline regarding the configuration
> properties?
>
>
> On 8/15/06, Patrick Linskey (JIRA) <jira@apache.org> wrote:
>>
>> [ http://issues.apache.org/jira/browse/OPENJPA-12?
>> page=comments#action_12428175
>> ]
>>
>> Patrick Linskey commented on OPENJPA-12:
>> ----------------------------------------
>>
>> I know that we changed this in our JPA TCK test-running
>> environment via
>> the property setting. I guess the question at hand is whether the
>> default
>> should be to be strict or to be lenient for JPA installations.
>> Does anyone
>> have a dissenting opinion?
>>
>> > Default to strictIdentityTypes for JPA
>> > --------------------------------------
>> >
>> > Key: OPENJPA-12
>> > URL: http://issues.apache.org/jira/browse/
>> OPENJPA-12
>> > Project: OpenJPA
>> > Issue Type: Bug
>> > Components: jpa
>> > Reporter: Michael Dick
>> > Priority: Minor
>> > Attachments: patch.txt
>> >
>> >
>> > The default behavior with OpenJPA is to be very forgiving
>> regarding the
>> Primary Key types passed in when calling EntityManager.find or
>> EntityManager.getReference .
>> > For example if an Entity has an ID of type Long OpenJPA will
>> attempt to
>> convert anything that extend java.lang.Number and Strings (maybe
>> others).
>> > This is a nice feature, but I don't think it should be the default
>> behavior. The JPA spec indicates that an IllegalArgumentException
>> should be
>> thrown if the second argument is not a valid type for the Entity's
>> primary
>> key. There is some room for interpretation as to what constitutes
>> a valid
>> type, conversion for all Numbers makes sense, but String might be
>> pushing
>> it.
>> > Workaround :
>> > Add the following to persistence.xml
>> > <property name="openjpa.Compatibility"
>> value="strictIdentityValues=true"
>> />
>> > Proposed Solution :
>> > The OpenJPA compatibility plugin provides a mechanism to enforce
>> strict
>> identity checking (defaulting to false). There's no need to change
>> the
>> default in the kernel (other persistence apis like JDO might be more
>> lenient) so I propose changing the default in
>> PersistenceProductDerivation.beforeConfigurationLoad().
>> > Changing it there should only effect the JPA facade and leave the
>> OpenJPA kernel's default in place for other facades.
>> > The value may be overridden by adding the following property to
>> persistence.xml
>> > <property name="openjpa.Compatibility"
>> value="strictIdentityValues=false"
>> />
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/
>> software/jira
>>
>>
>>
>
>
> --
> -Michael Dick
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!