But the same problem exists also when querying a persistent class. In
ObjectDB only classes that already have persistent instances in the database
are checked. I assume that ORM implementations also check only classes that
are already in use rather than scanning the entire classpath.
Also, we can restrict the automatic search to one level, i.e. if a
persistent interface is implemented by a non persistent class or extended by
a non persistent interface - it will not be considered by JDO as implemented
by subclasses and sub interfaces of these classes and interfaces, unless
implements is specified explicitly again at their level.
----- Original Message -----
From: "Erik Bengtson" <[EMAIL PROTECTED]>
To: "Ilan Kirsh" <[EMAIL PROTECTED]>
Sent: Saturday, October 06, 2007 8:49 PM
Subject: Re: 'Implements' annotation and XML element
Not only cpu, but also memory costly solution if implements gets
deprecated, since you have to identify the implementations of a pc
interface by analysing all classes in jdo search path. Also not only
before enhancement but at runtime, like before evaluating a jdoql
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: Ilan Kirsh <[EMAIL PROTECTED]>
Date: Sat, 06 Oct 2007 20:22:06
To:JDO Expert Group <[EMAIL PROTECTED]>, [email protected]
Cc:[EMAIL PROTECTED]
Subject: Re: 'Implements' annotation and XML element
Hi Erik,
You are right that without the Implements annotation / element, a few more
interfaces will have to be loaded by the implementation (at least during
enhancement), but is it really an issue? By the way, with
'persistence-capable-superclass' you could also avoid loading the non
persistence capable super class going directly to the first persistence
capable super class.
However, because duplication in development is very bad, and the extra
processing time is negligible - I suggest to deprecate Implements.
Craig, should I update the JIRA?
Ilan
----- Original Message -----
From: "Erik Bengtson" <[EMAIL PROTECTED]>
To: "Ilan Kirsh" <[EMAIL PROTECTED]>
Sent: Saturday, October 06, 2007 8:05 PM
Subject: Re: 'Implements' annotation and XML element
I mean in super pc you have a 1-1 association, and by the moment you need
to know the super pc class, you have already loaded the pc class, while
implements has a 1-N, where N is not a fixed number
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: "Erik Bengtson" <[EMAIL PROTECTED]>
Date: Sat, 6 Oct 2007 17:53:12
To:"Ilan Kirsh" <[EMAIL PROTECTED]>
Subject: Re: 'Implements' annotation and XML element
I think the utility is go cases where classes have not been loaded.
Example: schema creation does not need to load all pc classes to discover
which ones implements the interface, but only those declared.
While super pc class is used for discovery in bottom-up(child pc->super),
implements is top-down (interface->classes)
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: Ilan Kirsh <[EMAIL PROTECTED]>
Date: Sat, 06 Oct 2007 19:17:42
To:JDO Expert Group <[EMAIL PROTECTED]>
Subject: Fw: 'Implements' annotation and XML element
Sent again, now to [EMAIL PROTECTED]
----- Original Message -----
From: "Ilan Kirsh" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, October 05, 2007 1:15 AM
Subject: 'Implements' annotation and XML element
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
