You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Ilan Kirsh <ki...@objectdb.com> on 2007/09/25 19:18:07 UTC
JDO TCK 2.0 - Which set of tests to use?
Hi,
The JDO 2 TCK 2.0 package that is available for download at:
http://db.apache.org/jdo/releases/release-2.0.cgi
contains many invalid tests that have been fixed since that release.
In order to claim compliance with JDO 2 should I use the tests at:
http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
Should I fill CHALLENGE against tests in that set that IMO are invalid?
Thanks,
Ilan Kirsh
ObjectDB Software
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi Ilan,
It looks like there are 49 cases in which this test is not finding the
expected method signature in your implementation. Within this group,
there are three cases.
- There are 26 instances in which the impl declares a method abstract
and the test expects a concrete method.
- There are 21 cases where the test finds a fully qualified method name
and is expecting an unqualified name, as in:
--- missing constructor:
expected: public .JDOCanRetryException(java.lang.String,
java.lang.Throwable[], java.lang.Object)
class: public class javax.jdo.JDOCanRetryException extends
javax.jdo.JDOException
--- non-standard, public member;
found: public javax.jdo.JDOCanRetryException(java.lang.String,
java.lang.Throwable[], java.lang.Object)
class: public class javax.jdo.JDOCanRetryException extends
javax.jdo.JDOException
- There are 2 cases involving the static keyword where there is no
difference between the expected and found.
--- missing method:
expected: public static java.lang.Object[]
getObjectIds(java.lang.Object[])
class: public class javax.jdo.JDOHelper extends java.lang.Object
--- non-standard, public member;
found: public static java.lang.Object[]
getObjectIds(java.lang.Object[])
class: public class javax.jdo.JDOHelper extends java.lang.Object
The first case looks like an implementation issue, the last a test
issue. There are also 6 different ClassNotFoundExceptions that look like
a test issue. Perhaps Martin or Craig could take a look at the test.
I've attached some output files that are easier to read than the original.
-- Michelle
Ilan Kirsh wrote:
> Hi Michelle,
>
> I also need help with test app-runonce. Probably something in my test
> environment is not configured well to pass this test, but I have no
> idea what is it.
> Attached the jdo jar file that I am using and the output of that test.
> Any clue?
>
> Regards, Ilan
>
Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by Matthew Adams <ma...@matthewadams.org>.
+!, f'shizzle, we need to remizzle & dizzepricate.
(I don't know why I wrote my comment using Snooplang.
I must be punchy after talking for 4 days straight.)
--- cbeams <cb...@gmail.com> wrote:
> I haven't fully reviewed this proposal, but I do
> know that using
> implements/@Implements only served to confuse me in
> the past. I kept
> thinking: isn't this information superfluous?
> Should the enhancer
> have been able to figure this stuff out by static
> analysis?
>
> So if it is in fact not needed, I'm a big +1.
>
> Thanks,
>
> - Chris Beams
>
> On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:
>
> > Hi Ilan,
> >
> > +1 to remove/deprecate the implements element and
> @Implements
> > annotation.
> >
> > If no adverse comments are received by Tuesday
> October 16, it's gone.
> >
> > On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
> >
> >> Hi,
> >>
> >> The 'Implements' annotation (and the equivalent
> XML element)
> >> remind me
> >> the 'persistence-capable-superclass' XML
> attribute that is
> >> deprecated now.
> >
> > Yes, for JDO 1, we tried to have it possible to
> enhance classes
> > when not all of its dependencies (superclasses and
> implemented
> > interfaces) were available for loading and
> analysis. In this
> > environment, it was necessary to explicitly
> declare which
> > interfaces were implemented because you could not
> load all of the
> > directly implemented interfaces to see which
> persistence-capable
> > interfaces were indirectly inherited.
> >
> > But now, enhancement requires access to the entire
> inheritance tree
> > and it makes sense to also require the implements
> tree as well.
> >>
> >> If persistence capable interfaces are marked as
> such by annotations
> >> (or in the XML metadata), why should we have this
> duplication?
> >>
> >> Implementations should be able to find
> implemented persistence
> >> capable
> >> interfaces as they find a super persistence
> capable class.
> >
> > True, and I support deprecating the xml attribute
> and removing the
> > @Implements annotation.
> >
> > Unless someone can justify why there would be any
> semantic
> > difference between explicitly declaring the
> interfaces versus the
> > enhancer finding them. The only thing I can think
> of is whether an
> > explicitly named interface would have an extent
> managed, but I
> > think that you can only query over the extent of
> classes/interfaces
> > that themselves declare that an extent is managed.
> >
> > Craig
> >>
> >> Ilan Kirsh
> >> ObjectDB Software
> >> http://www.objectdb.com
> >>
> >>
> >
> > 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!
> >
>
>
Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by cbeams <cb...@gmail.com>.
I haven't fully reviewed this proposal, but I do know that using
implements/@Implements only served to confuse me in the past. I kept
thinking: isn't this information superfluous? Should the enhancer
have been able to figure this stuff out by static analysis?
So if it is in fact not needed, I'm a big +1.
Thanks,
- Chris Beams
On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:
> Hi Ilan,
>
> +1 to remove/deprecate the implements element and @Implements
> annotation.
>
> If no adverse comments are received by Tuesday October 16, it's gone.
>
> On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
>
>> Hi,
>>
>> The 'Implements' annotation (and the equivalent XML element)
>> remind me
>> the 'persistence-capable-superclass' XML attribute that is
>> deprecated now.
>
> Yes, for JDO 1, we tried to have it possible to enhance classes
> when not all of its dependencies (superclasses and implemented
> interfaces) were available for loading and analysis. In this
> environment, it was necessary to explicitly declare which
> interfaces were implemented because you could not load all of the
> directly implemented interfaces to see which persistence-capable
> interfaces were indirectly inherited.
>
> But now, enhancement requires access to the entire inheritance tree
> and it makes sense to also require the implements tree as well.
>>
>> If persistence capable interfaces are marked as such by annotations
>> (or in the XML metadata), why should we have this duplication?
>>
>> Implementations should be able to find implemented persistence
>> capable
>> interfaces as they find a super persistence capable class.
>
> True, and I support deprecating the xml attribute and removing the
> @Implements annotation.
>
> Unless someone can justify why there would be any semantic
> difference between explicitly declaring the interfaces versus the
> enhancer finding them. The only thing I can think of is whether an
> explicitly named interface would have an extent managed, but I
> think that you can only query over the extent of classes/interfaces
> that themselves declare that an extent is managed.
>
> Craig
>>
>> Ilan Kirsh
>> ObjectDB Software
>> http://www.objectdb.com
>>
>>
>
> 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!
>
Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
+1 to remove/deprecate the implements element and @Implements
annotation.
If no adverse comments are received by Tuesday October 16, it's gone.
On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
> Hi,
>
> The 'Implements' annotation (and the equivalent XML element) remind me
> the 'persistence-capable-superclass' XML attribute that is
> deprecated now.
Yes, for JDO 1, we tried to have it possible to enhance classes when
not all of its dependencies (superclasses and implemented interfaces)
were available for loading and analysis. In this environment, it was
necessary to explicitly declare which interfaces were implemented
because you could not load all of the directly implemented interfaces
to see which persistence-capable interfaces were indirectly inherited.
But now, enhancement requires access to the entire inheritance tree
and it makes sense to also require the implements tree as well.
>
> If persistence capable interfaces are marked as such by annotations
> (or in the XML metadata), why should we have this duplication?
>
> Implementations should be able to find implemented persistence capable
> interfaces as they find a super persistence capable class.
True, and I support deprecating the xml attribute and removing the
@Implements annotation.
Unless someone can justify why there would be any semantic difference
between explicitly declaring the interfaces versus the enhancer
finding them. The only thing I can think of is whether an explicitly
named interface would have an extent managed, but I think that you
can only query over the extent of classes/interfaces that themselves
declare that an extent is managed.
Craig
>
> Ilan Kirsh
> ObjectDB Software
> http://www.objectdb.com
>
>
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!
'Implements' annotation and XML element
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi,
The 'Implements' annotation (and the equivalent XML element) remind me
the 'persistence-capable-superclass' XML attribute that is deprecated now.
If persistence capable interfaces are marked as such by annotations
(or in the XML metadata), why should we have this duplication?
Implementations should be able to find implemented persistence capable
interfaces as they find a super persistence capable class.
Ilan Kirsh
ObjectDB Software
http://www.objectdb.com
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Michelle Caisse <Mi...@Sun.COM>.
You'll have to enter a challenge on those and we'll back port the
changes to a 2.0.x branch or add the test to the exclude list.
To initiate a challenge "send email to: jdo-dev@db.apache.org
<ma...@db.apache.org> with a subject line containing
"CHALLENGE" and the name of the test program, e.g.
org.apache.jdo.tck.api.persistencemanager.ThreadSafe.java; and the body
of the email containing the details of the challenge." You can just
reference the JIRAs for the details.
Thanks,
Michelle
Ilan Kirsh wrote:
> Hi Michelle,
>
> That was very helpful. Running this branch looks much better.
>
> Still I have problems with the following tests:
>
> 1. FetchPlanInterface.testGroups (fixed in JDO-402, after 2.0.1?)
> 2. ResultClassRequirements.testNegative (fixed in JDO-524)
> 3. ChangeQuery.testPositive (fixed in JDO-529)
> 4. ImplicitParameters.testGrouping (fixed in JDO-530)
> 5. StateTransitionsReturnedObjects (JDO-513, JDO-514).
>
> Please advise.
>
> Thanks, Ilan
>
>
> ----- Original Message ----- From: "Michelle Caisse"
> <Mi...@Sun.COM>
> To: <jd...@db.apache.org>
> Cc: "JDO Expert Group" <jd...@Sun.COM>
> Sent: Tuesday, September 25, 2007 8:46 PM
> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>
>
>> Hi Ilan,
>>
>> There is a source branch 2.01 with changes responsive to some earlier
>> challenges. There's a wiki page documenting the issues
>> http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from
>> svn
>> and let us know if there are remaining issues.
>>
>> Thanks,
>> Michelle
>>
>> Ilan Kirsh wrote:
>>> Is there an approved exclude list for the original JDO 2 TCK 2.0
>>> that is more realistic than the bundled list of 2 enhancement tests?
>>>
>>> If not, when ready, I can publish my exclude list as a suggestion.
>>>
>>> Regards, Ilan
>>>
>>> ----- Original Message ----- From: Craig L Russell To: JDO
>>> Expert Group Cc: Apache JDO project Sent:
>>> Tuesday, September 25, 2007 7:32 PM
>>> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>>>
>>>
>>> Hi Ilan,
>>>
>>>
>>>
>>>
>>> On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>>>
>>>
>>> Hi,
>>>
>>> The JDO 2 TCK 2.0 package that is available for download at:
>>> http://db.apache.org/jdo/releases/release-2.0.cgi
>>> contains many invalid tests that have been fixed since that
>>> release.
>>>
>>>
>>> Correct. The latest trunk has updated tests.
>>>
>>>
>>> In order to claim compliance with JDO 2 should I use the tests at:
>>> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>>>
>>>
>>> Well, there's no official release of the JDO 2.1 test suite, so
>>> probably to claim compliance with JDO 2.0, you should update the
>>> exclude
>>> list and run the original tests. And you should take a look at the tck2
>>> project as well.
>>>
>>>
>>> Should I fill CHALLENGE against tests in that set that IMO are
>>> invalid?
>>>
>>>
>>> Yes. We still have time to fix these before official release.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Thank you for your continued support.
>>>
>>>
>>> Craig
>>>
>>>
>>> Ilan Kirsh
>>> ObjectDB Software
>>>
>>>
>>>
>>>
>>> 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!
>>>
>>>
>>>
>>>
>>
>
>
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi Michelle,
That was very helpful. Running this branch looks much better.
Still I have problems with the following tests:
1. FetchPlanInterface.testGroups (fixed in JDO-402, after 2.0.1?)
2. ResultClassRequirements.testNegative (fixed in JDO-524)
3. ChangeQuery.testPositive (fixed in JDO-529)
4. ImplicitParameters.testGrouping (fixed in JDO-530)
5. StateTransitionsReturnedObjects (JDO-513, JDO-514).
Please advise.
Thanks, Ilan
----- Original Message -----
From: "Michelle Caisse" <Mi...@Sun.COM>
To: <jd...@db.apache.org>
Cc: "JDO Expert Group" <jd...@Sun.COM>
Sent: Tuesday, September 25, 2007 8:46 PM
Subject: Re: JDO TCK 2.0 - Which set of tests to use?
> Hi Ilan,
>
> There is a source branch 2.01 with changes responsive to some earlier
> challenges. There's a wiki page documenting the issues
> http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from svn
> and let us know if there are remaining issues.
>
> Thanks,
> Michelle
>
> Ilan Kirsh wrote:
>> Is there an approved exclude list for the original JDO 2 TCK 2.0
>> that is more realistic than the bundled list of 2 enhancement tests?
>>
>> If not, when ready, I can publish my exclude list as a suggestion.
>>
>> Regards, Ilan
>>
>> ----- Original Message -----
>> From: Craig L Russell To: JDO Expert Group Cc: Apache JDO project Sent:
>> Tuesday, September 25, 2007 7:32 PM
>> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>>
>>
>> Hi Ilan,
>>
>>
>>
>>
>> On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>>
>>
>> Hi,
>>
>> The JDO 2 TCK 2.0 package that is available for download at:
>> http://db.apache.org/jdo/releases/release-2.0.cgi
>> contains many invalid tests that have been fixed since that release.
>>
>>
>> Correct. The latest trunk has updated tests.
>>
>>
>> In order to claim compliance with JDO 2 should I use the tests at:
>> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>>
>>
>> Well, there's no official release of the JDO 2.1 test suite, so
>> probably to claim compliance with JDO 2.0, you should update the exclude
>> list and run the original tests. And you should take a look at the tck2
>> project as well.
>>
>>
>> Should I fill CHALLENGE against tests in that set that IMO are
>> invalid?
>>
>>
>> Yes. We still have time to fix these before official release.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Thank you for your continued support.
>>
>>
>> Craig
>>
>>
>> Ilan Kirsh
>> ObjectDB Software
>>
>>
>>
>>
>> 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!
>>
>>
>>
>>
>
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Michelle Caisse <Mi...@Sun.COM>.
Hi Ilan,
There is a source branch 2.01 with changes responsive to some earlier
challenges. There's a wiki page documenting the issues
http://wiki.apache.org/jdo/TCKChallenges. Please get this branch from
svn and let us know if there are remaining issues.
Thanks,
Michelle
Ilan Kirsh wrote:
> Is there an approved exclude list for the original JDO 2 TCK 2.0
> that is more realistic than the bundled list of 2 enhancement tests?
>
> If not, when ready, I can publish my exclude list as a suggestion.
>
> Regards, Ilan
>
> ----- Original Message -----
> From: Craig L Russell
> To: JDO Expert Group
> Cc: Apache JDO project
> Sent: Tuesday, September 25, 2007 7:32 PM
> Subject: Re: JDO TCK 2.0 - Which set of tests to use?
>
>
> Hi Ilan,
>
>
>
>
> On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
>
>
> Hi,
>
> The JDO 2 TCK 2.0 package that is available for download at:
> http://db.apache.org/jdo/releases/release-2.0.cgi
> contains many invalid tests that have been fixed since that release.
>
>
> Correct. The latest trunk has updated tests.
>
>
> In order to claim compliance with JDO 2 should I use the tests at:
> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
>
>
> Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.
>
>
> Should I fill CHALLENGE against tests in that set that IMO are invalid?
>
>
> Yes. We still have time to fix these before official release.
>
>
>
> Thanks,
>
>
>
> Thank you for your continued support.
>
>
> Craig
>
>
> Ilan Kirsh
> ObjectDB Software
>
>
>
>
> 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!
>
>
>
>
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Ilan Kirsh <ki...@objectdb.com>.
Is there an approved exclude list for the original JDO 2 TCK 2.0
that is more realistic than the bundled list of 2 enhancement tests?
If not, when ready, I can publish my exclude list as a suggestion.
Regards, Ilan
----- Original Message -----
From: Craig L Russell
To: JDO Expert Group
Cc: Apache JDO project
Sent: Tuesday, September 25, 2007 7:32 PM
Subject: Re: JDO TCK 2.0 - Which set of tests to use?
Hi Ilan,
On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
Hi,
The JDO 2 TCK 2.0 package that is available for download at:
http://db.apache.org/jdo/releases/release-2.0.cgi
contains many invalid tests that have been fixed since that release.
Correct. The latest trunk has updated tests.
In order to claim compliance with JDO 2 should I use the tests at:
http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
Well, there's no official release of the JDO 2.1 test suite, so probably to claim compliance with JDO 2.0, you should update the exclude list and run the original tests. And you should take a look at the tck2 project as well.
Should I fill CHALLENGE against tests in that set that IMO are invalid?
Yes. We still have time to fix these before official release.
Thanks,
Thank you for your continued support.
Craig
Ilan Kirsh
ObjectDB Software
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!
Re: Persistence Capable Interfaces and Abstract Classes
Posted by cbeams <cb...@gmail.com>.
Okay, thanks. At any rate, I want this simple functionality from
newQuery(Type.class) where Type is a PC interface. Hope this makes
sense.
- Chris
On Sep 27, 2007, at 5:19 PM, Ilan Kirsh wrote:
> Hi Chris,
>
> Actually you need to use Extent to exclude subclasses. To include
> subclasses
> you can use a candidate class, as described in section 14.6:
>
> If the candidates are not specified explicitly by newQuery,
> setCandidates(Collection), or setCandidates(Extent), then the
> candidate
> extent is the extent of instances of the candidate class in the
> datastore
> including subclasses. That is, the candidates are the result of
> getPersistenceManager().getExtent(candidateClass, true).
>
> Regards, Ilan
>
> ----- Original Message ----- From: "cbeams" <cb...@gmail.com>
> To: <jd...@db.apache.org>
> Cc: "Craig L Russell" <Cr...@Sun.COM>; "JDO Expert Group"
> <jd...@Sun.COM>
> Sent: Friday, September 28, 2007 1:35 AM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
>
>> As we continue considering what Persistent Interfaces are really all
>> about in the 2.1 timeline, let me reiterate my original need /
>> expectation with this:
>>
>> If I have a PC class MyPerson that implements persistent interface
>> Person:
>>
>> public class Person {}
>> public class MyPerson implements Person {}
>>
>>
>> I expect that I should be able to query by the person interface and
>> retrieve all persistent instances of objects assignable to that
>> interface:
>>
>> List<Person> people = (List<Person>) pm.newQuery
>> (Person.class).execute();
>>
>> Note here that I'm not using an Extent. Typically, to return
>> subtypes, we would need to do something like:
>>
>> pm.newQuery(new Extent(Person.class, true)); //...
>>
>> However, this makes no sense when the type in question is an
>> interface. Thus I propose that queries taking interfaces as
>> parameters implicitly return all implementing persistent instances.
>>
>> I believe that this scenario represents the most basic, intuitive
>> kind of use case possible when dealing with interfaces. And, it is
>> currently not supported.
>>
>> Note that what I'm talking about here does not take into account any
>> of the support for implementation generation (pm.newInstance()),
>> etc.. I consider all that functionality, while perhaps useful, to be
>> much more advanced.
>>
>> Thanks,
>>
>> - Chris
>>
>> Chris Beams
>>
>>
>> On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
>>
>>> Thanks. It might be appropriate to mention persistent interfaces
>>> also in chapter 6.
>>>
>>> Ilan
>>> ----- Original Message -----
>>> From: Craig L Russell
>>> To: Ilan Kirsh
>>> Cc: jdo-dev@db.apache.org ; JDO Expert Group
>>> Sent: Wednesday, September 26, 2007 6:00 PM
>>> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>>>
>>> Hi Ilan,
>>>
>>> You could start with the pm.newInstance method in 12.6.6 that is
>>> the way to instantiate the instances, and then look at the metadata
>>> descriptions in 18.5.
>>>
>>> Craig
>>>
>>> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>>>
>>>> I wonder where in the spec persistence capable interfaces and
>>>> persistence capable abstract classes are discussed.
>>>> I have the Java Data Objects 2.1 specification draft from 13 June
>>>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>>>> this issue.
>>>>
>>>> Ilan
>>>>
>>>>
>>>
>>> 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!
>>>
>>>
>>
>>
>
>
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Ilan Kirsh <ki...@objectdb.com>.
Hi Chris,
Actually you need to use Extent to exclude subclasses. To include subclasses
you can use a candidate class, as described in section 14.6:
If the candidates are not specified explicitly by newQuery,
setCandidates(Collection), or setCandidates(Extent), then the candidate
extent is the extent of instances of the candidate class in the datastore
including subclasses. That is, the candidates are the result of
getPersistenceManager().getExtent(candidateClass, true).
Regards, Ilan
----- Original Message -----
From: "cbeams" <cb...@gmail.com>
To: <jd...@db.apache.org>
Cc: "Craig L Russell" <Cr...@Sun.COM>; "JDO Expert Group"
<jd...@Sun.COM>
Sent: Friday, September 28, 2007 1:35 AM
Subject: Re: Persistence Capable Interfaces and Abstract Classes
> As we continue considering what Persistent Interfaces are really all
> about in the 2.1 timeline, let me reiterate my original need /
> expectation with this:
>
> If I have a PC class MyPerson that implements persistent interface
> Person:
>
> public class Person {}
> public class MyPerson implements Person {}
>
>
> I expect that I should be able to query by the person interface and
> retrieve all persistent instances of objects assignable to that
> interface:
>
> List<Person> people = (List<Person>) pm.newQuery
> (Person.class).execute();
>
> Note here that I'm not using an Extent. Typically, to return
> subtypes, we would need to do something like:
>
> pm.newQuery(new Extent(Person.class, true)); //...
>
> However, this makes no sense when the type in question is an
> interface. Thus I propose that queries taking interfaces as
> parameters implicitly return all implementing persistent instances.
>
> I believe that this scenario represents the most basic, intuitive
> kind of use case possible when dealing with interfaces. And, it is
> currently not supported.
>
> Note that what I'm talking about here does not take into account any
> of the support for implementation generation (pm.newInstance()),
> etc.. I consider all that functionality, while perhaps useful, to be
> much more advanced.
>
> Thanks,
>
> - Chris
>
> Chris Beams
>
>
> On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
>
>> Thanks. It might be appropriate to mention persistent interfaces
>> also in chapter 6.
>>
>> Ilan
>> ----- Original Message -----
>> From: Craig L Russell
>> To: Ilan Kirsh
>> Cc: jdo-dev@db.apache.org ; JDO Expert Group
>> Sent: Wednesday, September 26, 2007 6:00 PM
>> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>>
>> Hi Ilan,
>>
>> You could start with the pm.newInstance method in 12.6.6 that is
>> the way to instantiate the instances, and then look at the metadata
>> descriptions in 18.5.
>>
>> Craig
>>
>> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>>
>>> I wonder where in the spec persistence capable interfaces and
>>> persistence capable abstract classes are discussed.
>>> I have the Java Data Objects 2.1 specification draft from 13 June
>>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>>> this issue.
>>>
>>> Ilan
>>>
>>>
>>
>> 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!
>>
>>
>
>
Re: Persistence Capable Interfaces and Abstract Classes
Posted by cbeams <cb...@gmail.com>.
As we continue considering what Persistent Interfaces are really all
about in the 2.1 timeline, let me reiterate my original need /
expectation with this:
If I have a PC class MyPerson that implements persistent interface
Person:
public class Person {}
public class MyPerson implements Person {}
I expect that I should be able to query by the person interface and
retrieve all persistent instances of objects assignable to that
interface:
List<Person> people = (List<Person>) pm.newQuery
(Person.class).execute();
Note here that I'm not using an Extent. Typically, to return
subtypes, we would need to do something like:
pm.newQuery(new Extent(Person.class, true)); //...
However, this makes no sense when the type in question is an
interface. Thus I propose that queries taking interfaces as
parameters implicitly return all implementing persistent instances.
I believe that this scenario represents the most basic, intuitive
kind of use case possible when dealing with interfaces. And, it is
currently not supported.
Note that what I'm talking about here does not take into account any
of the support for implementation generation (pm.newInstance()),
etc.. I consider all that functionality, while perhaps useful, to be
much more advanced.
Thanks,
- Chris
Chris Beams
On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
> Thanks. It might be appropriate to mention persistent interfaces
> also in chapter 6.
>
> Ilan
> ----- Original Message -----
> From: Craig L Russell
> To: Ilan Kirsh
> Cc: jdo-dev@db.apache.org ; JDO Expert Group
> Sent: Wednesday, September 26, 2007 6:00 PM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
> Hi Ilan,
>
> You could start with the pm.newInstance method in 12.6.6 that is
> the way to instantiate the instances, and then look at the metadata
> descriptions in 18.5.
>
> Craig
>
> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>
>> I wonder where in the spec persistence capable interfaces and
>> persistence capable abstract classes are discussed.
>> I have the Java Data Objects 2.1 specification draft from 13 June
>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>> this issue.
>>
>> Ilan
>>
>>
>
> 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!
>
>
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
Good point. Persistent interfaces is on my list to discuss in the
spec, and I'll add Abstract Classes as a topic in the same light.
Craig
On Sep 27, 2007, at 2:55 PM, Ilan Kirsh wrote:
> Thanks. It might be appropriate to mention persistent interfaces
> also in chapter 6.
>
> Ilan
> ----- Original Message -----
> From: Craig L Russell
> To: Ilan Kirsh
> Cc: jdo-dev@db.apache.org ; JDO Expert Group
> Sent: Wednesday, September 26, 2007 6:00 PM
> Subject: Re: Persistence Capable Interfaces and Abstract Classes
>
> Hi Ilan,
>
> You could start with the pm.newInstance method in 12.6.6 that is
> the way to instantiate the instances, and then look at the metadata
> descriptions in 18.5.
>
> Craig
>
> On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
>
>> I wonder where in the spec persistence capable interfaces and
>> persistence capable abstract classes are discussed.
>> I have the Java Data Objects 2.1 specification draft from 13 June
>> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
>> this issue.
>>
>> Ilan
>>
>>
>
> 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!
>
>
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!
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Ilan Kirsh <ki...@objectdb.com>.
Thanks. It might be appropriate to mention persistent interfaces also in chapter 6.
Ilan
----- Original Message -----
From: Craig L Russell
To: Ilan Kirsh
Cc: jdo-dev@db.apache.org ; JDO Expert Group
Sent: Wednesday, September 26, 2007 6:00 PM
Subject: Re: Persistence Capable Interfaces and Abstract Classes
Hi Ilan,
You could start with the pm.newInstance method in 12.6.6 that is the way to instantiate the instances, and then look at the metadata descriptions in 18.5.
Craig
On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.
I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6) ignore this issue.
Ilan
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!
Re: Persistence Capable Interfaces and Abstract Classes
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
You could start with the pm.newInstance method in 12.6.6 that is the
way to instantiate the instances, and then look at the metadata
descriptions in 18.5.
Craig
On Sep 26, 2007, at 2:46 AM, Ilan Kirsh wrote:
> I wonder where in the spec persistence capable interfaces and
> persistence capable abstract classes are discussed.
> I have the Java Data Objects 2.1 specification draft from 13 June
> 2007, and it seems that relevant sections (e.g. chapter 6) ignore
> this issue.
>
> Ilan
>
>
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!
Persistence Capable Interfaces and Abstract Classes
Posted by Ilan Kirsh <ki...@objectdb.com>.
I wonder where in the spec persistence capable interfaces and persistence capable abstract classes are discussed.
I have the Java Data Objects 2.1 specification draft from 13 June 2007, and it seems that relevant sections (e.g. chapter 6) ignore this issue.
Ilan
Re: JDO TCK 2.0 - Which set of tests to use?
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ilan,
On Sep 25, 2007, at 10:18 AM, Ilan Kirsh wrote:
> Hi,
>
> The JDO 2 TCK 2.0 package that is available for download at:
> http://db.apache.org/jdo/releases/release-2.0.cgi
> contains many invalid tests that have been fixed since that release.
Correct. The latest trunk has updated tests.
>
> In order to claim compliance with JDO 2 should I use the tests at:
> http://svn.apache.org/viewvc/db/jdo/trunk/tck2-legacy/ ?
Well, there's no official release of the JDO 2.1 test suite, so
probably to claim compliance with JDO 2.0, you should update the
exclude list and run the original tests. And you should take a look
at the tck2 project as well.
>
> Should I fill CHALLENGE against tests in that set that IMO are
> invalid?
Yes. We still have time to fix these before official release.
>
> Thanks,
>
Thank you for your continued support.
Craig
> Ilan Kirsh
> ObjectDB Software
>
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!