Re: PersistenceManager extends Serializable
If the instances in cache are not serializable, then an exception gets thrown at runtime when the instance in cache tries to serialize. (of course a PM might be "super smart" and might know how to serialize a PersistanceCapable instanc. Heck, it already knows how to map a PC to a database). :-) -geoff - Original Message From: Michael Bouschen <[EMAIL PROTECTED]> To: jdo-dev@db.apache.org Cc: JDO Expert Group <[EMAIL PROTECTED]> Sent: Wednesday, October 18, 2006 2:43:43 PM Subject: Re: PersistenceManager extends Serializable Hi Craig, I think this is a good idea, since it would allow storing a PersistenceManager as a session attribute (for whatever purpose). The interesting question is whether any caches get serialized along with the PersistenceManager? What happens with cached persistent instances of a non-serializable class? Regards Michael > Javadogs, > > For easier development of web applications, it would be nice if > PersistenceManager were Serializable. There is nothing stopping an > implementation from declaring that their implementation extends > Serializable, but the behavior is implementation-specific. > > For the maintenance release, I'd like to see if we can agree on the > behavior of serializing a PersistenceManager if it does implement > Serializable. > > Craig > > Craig Russell > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > 408 276-5638 mailto:[EMAIL PROTECTED] > > P.S. A good JDO? O, Gasp! > > -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33Buelowstr. 66 Fax.:++49/30/2175 2012D-10783 Berlin
Re: Proposal for new method (long)
How do we deal with the fact that any components stored in a Page state (wicket/tapestry lingo) need to be serializable? In the case of wicket, Page is serialized all the time, not just when clustering is applies. The pages are serialized and deserialized in order to minimize the memory footprint of an application when there are lots of concurrent sessions. You can't put ANYTHING into the Servlet session, or any page state variable, in any real application, that isn't serializable. If you do, you are back to the "sodding" solutions of proxies, activation/passivation-type callbacks, hell-on-earth-bad-programming-paradigms. In Shades, I've addressed this by making the DatabaseSession (equivalent to PM) serializable. This is possible because the DatabaseSession does not hang on to connections. Also, I mentioned a long time ago that users WOULD want to keep a PersistenceManager-per-session, and I recall postings on JDO central where users asked for it. There seemed to be very little support for this idea. I'm following this thread somewhat loosly, but are we now saying PM-per-session is a valid pattern that we want to support? At the time I proposed this, detachment was the prefered alternative. (I continiue to believe detachment is an anti-pattern that arrises because of the non-serializability problem of the PM, and in situations where the web programming model is fundamentally broken ...E.G Struts). OK, I've stirred the pot a bit. :-) don't take it the wrong way. -geoff - Original Message From: Wes Biggs <[EMAIL PROTECTED]> To: Craig L Russell <[EMAIL PROTECTED]> Cc: JDO Experts Group <[EMAIL PROTECTED]>; Apache JDO project Sent: Wednesday, October 11, 2006 5:42:24 AM Subject: Re: Proposal for new method (long) Craig, I've used this approach myself, and found it to generally improve productivity in web application development. However, I would question whether enshrining it in the API is really that valuable. There are definite limitations to the usefulness of a ThreadLocal PM, from the obvious one of not being able to easily share it in threaded subtasks (producer-consumer, for example, or other scenarios where a web request initiates an asynchronous action), to the lack of ability to control PM lifecycle (from a user perspective) and the lack of ability to optimize PM reuse and caching (from a provider perspective). ThreadLocals are also notoriously difficult to debug, particularly in the area of memory leaks. Undoubtedly there are techniques to get around all of those, but let's just say it's not a silver bullet. Apart from the J2EE integration scenario, it's trivially easy for the user (or a web framework component) to create a ThreadLocal PM helper method; the API is public (unlike most JDOHelper methods, which rely on "hidden methods" and an SPI layer). Now, with that all said, I support anything that helps get us closer to truly transparent persistence, which I define as "not having to worry about the sodding PMF or PM". What I'd really like to see is a configuration/injection method (per environment -- SE and EE) that makes it as trivial as possible to get a PM and start doing some real work. At the most (and overly) basic level, this becomes PersistenceManager.getInstance(), and the environment is responsible for determining exactly where the instance comes from. In this context, ThreadLocal is a particular configuration strategy that may suit some applications. The persistence unit concept -- or for our purposes, named PMFs -- is a useful bridge between configuring the environment (runtime) and configuring the application (design time). For example, I might want to configure the environment such that PM.getInstance(), when called from any Tomcat threadpool thread (I think this could be done by ClassLoader), uses, as its secret sauce, a ThreadLocal PersistenceManager that comes from the "persistence-unit1" PMF configuration. You could take the approach of adding, e.g., javax.jdo.ThreadLocal=true to the PMF properties, but I think that unnecessarily mixes the data access configuration with the application environment's usage of that configuration. So -- I like the ability to have a ThreadLocal PM setup. But it seems like we could do more here than just enshrine that one pattern. I like the ability to use PersistenceUnitNames to look up PMFs. I think this should be available regardless of the proxy scenario, via JDOHelper.getNamedPersistenceManagerFactory(String name) (or possibly overriding the semantics of getPersistenceManagerFactory(String) -- have to think about that). The requirement is that when loading a PMF, it is interrogated for its name and registered in a hash on JDOHelper. It's possible I've completely jumped the shark here, and if so I apologize and await the hail of bullets, but I hope I may provoke some interesting discussion. Thoughts? Wes Craig L Russell wrote: > Javadogs, > >
Re: The Future of JDO
Hi All, It's been a while since I've posted. I've taken down the JDOMax website, and I'm now focusing my efforts on Shades. http://sourceforge.net/projects/shadesdb I continue to think that JDO is a leap forward, and I continue to share my great experiences as both a user of JDO and an implementer. Unfortunately, just keeping up with the TCK was becoming a goal in and of itself, and eventually I realized one guy simply can't do it. Therefore, I decided to refocus my efforts on smaller core of great ideas that came in part from working on JDOMax. I'm hoping that by working closely with the Wicket community, I can insure that Shades evolves iteratively and meets the needs of a focused user base. I'd like to offer up that one thing the JDO community could do to drive adoption is insure that JDO implementers work closely with other framework communities, Like Wicket, Tapestry, Webwork, etc. For example, Wicket has a project called "phonebook" which is a best practices example for using data access frameworks through Spring. Ibatis and Hibernate are represented, and I'll add Shades soon. talk soon, geoff - Original Message From: Erik Bengtson <[EMAIL PROTECTED]> To: jdo-dev@db.apache.org; JDO Expert Group <[EMAIL PROTECTED]> Sent: Thursday, October 5, 2006 5:43:26 AM Subject: Re: The Future of JDO > > The fact that JPA has not really had much impact (that is the > perception out there, I don't know the reality, but in the market it > is perception that matters) does give JDO a new opportunity to rise > up and be reconsidered. > This is very important point, but maybe optimistic. I would say that's the last opportunity for JDO to get some traction. In my packet for JDO 2.1 / 3, I would include services around the API like failover, transaction recovery, management and monitoring. I dont't see much things more where JDO could differ from JPA. On the other side JPA has support from big vendors, and in one way or other this is very confortable for short term / long term while JDO is perceived as dead by many. I would love to spend more time on marketing however time is short and market needs to be followed by execution capacity which, for JPOX at least is limited by number of contributors. Regards
Re: VOTE: Release JDO 2.0 API project
[X] release JDO 2.0 API --- Craig L Russell <[EMAIL PROTECTED]> wrote: > PMC members, > > [ ] release JDO 2.0 API > [ ] do not release JDO 2.0 API because: > > This vote will be open until Monday 3-Apr-2006. > > This is a vote to release the JDO 2.0 API project > that was approved > by the JDO expert group and by the Apache JDO > project. The bits have > been tested and passed. > > There are four projects that are in the staging area > http:// > people.apache.org/~clr/downloads > > The API project needs to be released final in order > to synchronize > with the JPOX release that depends on it. The TCK > project has to wait > for the JPOX release, so we are not voting on that > project release at > this time. > > > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
Re: Negative VOTE: Spec update for xml metadata files
Are we sure we want to mandate the xsi:schemaLocation? Often times you want to point to a local copy of the schema. Once you've done a JAXB binding, it's not necessary at all for the schemaLocation to be specified. One thing I've run into with specifying the schemaLocation as http://yadayadayada is that you actually have to be online to run your unmarshalling software (at least with some versions of sun's JAXB). --- Craig L Russell <[EMAIL PROTECTED]> wrote: > Javadogs, > > Here's a change to the spec to accommodate the xsd > format for > metadata. These identify the schema namespace and > location where > the .xsd files will be posted after spec approval. > > The jdo Schema Descriptor > This describes files stored as .jdo files. > Note: The document type descriptors are descriptive, > not normative. > The xml schema in the binary distribution is > normative. > JDO vendors must support XSD and might support DTD. > If using XSD, the > declaration of the jdo element must include the > following: > > http://java.sun.com/xml/ns/jdo/jdo"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdo > http://java.sun.com/xml/ns/jdo/jdo_2_0.xsd";> > The document type descriptor is referred by the xml, > and must be > identified with a DOCTYPE so that the parser can > validate the syntax > of the metadata file. Either the SYSTEM or PUBLIC > form of DOCTYPE can > be used. > If SYSTEM is used, the URI must be accessible; a jdo > implementation > might optimize access for the URI > "http://java.sun.com/dtd/jdo_2_0.dtd"; > If PUBLIC is used, the public id should be "-//Sun > Microsystems, > Inc.//DTD Java Data Objects Metadata 2.0//EN"; a jdo > implementation > might optimize access for this id. > > The orm Schema Descriptor > This describes files stored as .orm files. > Note: The document type descriptors are descriptive, > not normative. > The xml schema in the binary distribution is > normative. > JDO vendors must support XSD and might support DTD. > If using XSD, the > declaration of the orm element must include the > following: > > http://java.sun.com/xml/ns/jdo/orm"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/orm > http://java.sun.com/xml/ns/jdo/orm_2_0.xsd";> > The document type descriptor is referred by the xml, > and must be > identified with a DOCTYPE so that the parser can > validate the syntax > of the metadata file. Either the SYSTEM or PUBLIC > form of DOCTYPE can > be used. > If SYSTEM is used, the URI must be accessible; a jdo > implementation > might optimize access for the URI > "http://java.sun.com/dtd/orm_2_0.dtd"; > If PUBLIC is used, the public id should be "-//Sun > Microsystems, > Inc.//DTD Java Data Objects Mapping Metadata > 2.0//EN"; a jdo > implementation might optimize access for this id. > > The jdoquery Schema Descriptor > This describes files stored as .jdoquery files. > Note: The document type descriptors are descriptive, > not normative. > The xml schema in the binary distribution is > normative. > JDO vendors must support XSD and might support DTD. > If using XSD, the > declaration of the jdoquery element must include the > following: > > xmlns="http://java.sun.com/xml/ns/jdo/jdoquery"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdoquery > http://java.sun.com/xml/ns/jdo/jdoquery_2_0.xsd";> > The document type descriptor is referred by the xml, > and must be > identified with a DOCTYPE so that the parser can > validate the syntax > of the metadata file. Either the SYSTEM or PUBLIC > form of DOCTYPE can > be used. > If SYSTEM is used, the URI must be accessible; a jdo > implementation > might optimize access for the URI > "http://java.sun.com/dtd/ > jdoquery_2_0.dtd" > If PUBLIC is used, the public id should be "-//Sun > Microsystems, > Inc.//DTD Java Data Objects Query Metadata 2.0//EN"; > a jdo > implementation might optimize access for this id. > > > > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
Re: [VOTE] Release jdo2 beta
My vote is uninformed since I have been unable to participate in the TCK process. But I give my yes vote. --- Craig L Russell <[EMAIL PROTECTED]> wrote: > Javadogs, > > I'd like to propose that we release jdo2 beta based > on the current > code in the svn repository and a few minor changes. > > 1. JDO-278 Change the group ids for the project from > apache-jdo to > > org.apache.jdo for the non-API projects > javax.jdo for the API projects. > > 2. Change the version on all projects to 2.0-beta. > This can be > changed when we make the JDO-278 changes. > > 3. JDO-279 Distribute the tck20 as a source > distribution and the > other components as downloadable binary components. > These would go > into the apache maven repository at > www.apache.org/dist/java-repository. > > I'd like to have everyone's vote by Thursday > 18-Jan-2006. > > Thanks, > > Craig > > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
Re: VOTE [URGENT] Issue 136: Change signature of makePersistent
+1 --- Craig L Russell <[EMAIL PROTECTED]> wrote: > Javadogs, > > I'd like to tally the vote on this issue by close of > business > Thursday 8-Dec-2005. > > This issue was renamed to highlight the interface > change. > > Please vote to adopt this proposal or offer a reason > to reject it. > It's the most significant change for a few months, > as it modifies the > core method of persistence. > > Rationale: There are so few differences between > makePersistent and > attachCopy, it's confusing. The only significant > differences between > the APIs is in the treatment of transient instances. > MakePersistent > makes transient instances transition to > persistent-new; attachCopy > copies transient instances. > > The proposal is to remove attachCopy, change the > signature of > makePersistent and makePersistentAll to return the > instance(s). > > The semantics of makePersistent change slightly from > the > specification. Currently, detached instances in the > object graph > cause an exception to be thrown. With this change, > detached instances > are located in the persistent cache and any dirty > fields are applied > to the persistent instance. > > With this change, there is no standard way to attach > the same object > graph to multiple persistence managers. If this > becomes an issue, we > can consider adding a method to JDOHelper that > copies a complete > object graph so the copies can be attached to > multiple persistence > managers. But practical experience has not shown > this to be an issue. > > > Object makePersistent (Object pc); > Object [] makePersistentAll (Object[] pcs); > Collection makePersistentAll (Collection pcs); > A12.5.7-6A [These methods make transient instances > persistent and > apply detached instance changes to the cache. They > must be called in > the context of an active transaction, or a > JDOUserException is > thrown.] A12.5.7-6B [For a transient instance, they > will assign an > object identity to the instance and transition it to > persistent-new.] > Any transient instances reachable from this instance > via persistent > fields of this instance will become provisionally > persistent, > transitively. That is, they behave as persistent-new > instances > (return true to isPersistent, isNew, and isDirty). > But A12.5.7-6C [at > commit time, the reachability algorithm is run > again, and instances > made provisionally persistent that are not currently > reachable from > persistent instances will revert to transient.] > For a detached instance, they locate or create a > persistent instance > with the same JDO identity as the detached instance, > and merge the > persistent state of the detached instance to the > persistent instance. > Only the state of persistent fields is merged. If > non-persistent > state needs to be copied, the application should use > the > jdoPostAttach callback or the postAttach lifecycle > event listener. > Any references to the detached instances from > instances in the > closure of the parameter instances are modified to > refer to the > corresponding persistent instance instead of to the > detached instance. > During application of changes of the detached state, > if the JDO > implementation can determine that there were no > changes made during > detachment, then the implementation is not required > to mark the > corresponding instance dirty. A12.6.8-28 [If it > cannot determine if > changes were made, then it must mark the instance > dirty.] > No consistency checking is done during > makePersistent. If consistency > checking is required by the application, then flush > or > checkConsistency should be called after attaching > the instances. > A12.5.7-7 [These methods have no effect on parameter > persistent > instances already managed by this > PersistenceManager.] A12.5.7-8 > [They will throw a JDOUserException if the parameter > instance is > managed by a different PersistenceManager.] > A12.6.7-1 [If an instance is of a class whose > identity type > (application, datastore, or none) is not supported > by the JDO > implementation, then a JDOUserException will be > thrown for that > instance.] > The return value for instances in the transient or > persistent states > is the same as the parameter value. The return value > for detached > instances is the persistent instance corresponding > to the detached > instance. > The return values for makePersistentAll methods > correspond by > position to the parameter instances. > > > > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: Latest JDO2 issues list
Issue 88 is resolved via some changed language in the spec, no? -geoff --- Craig L Russell <[EMAIL PROTECTED]> wrote: > Javadogs, > > We're making great progress on the issues list. > > Craig >  > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Re: TestFieldsOfObject patch
Well, I just bit the bullet and built in code to
serialize the objects when they are not PC's. Now that
we have a standardized mapping, this sort of ambiguity
will be harder to slide by, because the or-mapping
will be part of the test suite (right?).
-geoff
--- Craig Russell <[EMAIL PROTECTED]> wrote:
> Hi Michelle,
>
> The test from JDO 1.0 would probably not pass most
> non-object
> database JDO implementations. I'm disappointed that
> no one (many
> claimed to have passed the JDO 1.0 TCK) complained
> about this test.
>
> The changes you suggest are fine with me.
>
> Craig
>
> On Aug 20, 2005, at 8:58 AM, Michelle Caisse wrote:
>
> > Any objections?
> >
> > -- Michelle
> > Index:
> test/java/org/apache/jdo/tck/models/fieldtypes/
> > TestFieldsOfObject.java
> >
>
===
> > ---
> test/java/org/apache/jdo/tck/models/fieldtypes/
> > TestFieldsOfObject.java(revision 231272)
> > +++
> test/java/org/apache/jdo/tck/models/fieldtypes/
> > TestFieldsOfObject.java(working copy)
> > @@ -21,6 +21,7 @@
> >
> > import org.apache.jdo.tck.JDO_Test;
> > import
> org.apache.jdo.tck.pc.fieldtypes.FieldsOfObject;
> > +import
> org.apache.jdo.tck.pc.fieldtypes.SimpleClass;
> > import org.apache.jdo.tck.util.BatchTestRunner;
> >
> > /**
> > @@ -77,8 +78,8 @@
> > Transaction tx = pm.currentTransaction();
> > try {
> > int i, n;
> > -Object firstValue = new
> String("Hello");
> > -Object secondValue = new
> Integer("420");
> > +Object firstValue = new
> SimpleClass(1, "Hello");
> > +Object secondValue = new
> SimpleClass(333, "420");
> > tx.begin();
> > FieldsOfObject pi = new
> FieldsOfObject();
> > pi.identifier = 1;
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Embedded collections of non-PC objects
--- Andy Jefferson <[EMAIL PROTECTED]> wrote: > Hi Craig, > > thanks for your reply and your insights. > > > > Example 1 : Collection of BigDecimal > > > 1. Basic collection > > > > > > element-type="java.math.BigDecimal"/> > > > > > > > > > This creates 2 tables - 1 for the class owning > "myfield", and 1 > > > join table to > > > contain the elements. If is omitted then > an error should be > > > thrown > > > (though i'm not sure if JPOX currently flags > this up) > > > > The join element has no defaults, so this is not > sufficient to > > describe the mapping. You need at least a column > attribute naming the > > join column. And you need to name the column in > the join table to map > > the BigDecimal values to. So, > > > > table="MYFIELD_TABLE"> > > element-type="java.math.BigDecimal"/> > > > > > > I don't necessarily agree here. We have to qualify > the statement with the > following > New schema : The JDO impl is perfectly capable of > providing default namings > for columns and perfectly capable of choosing the > join columns ... since it > has the (PK) columns in the main table. It provides > default namings for > columns in other situations. > Existing schema : The user should specify the > columns and table as you stated. Andy, I totally appreciate that you are trying to provide your users with good forward mapping tools, but I agree with Craig. Personally I think the approach to forward schema genration should be to allow the user to start with a plain .jdo file (no ORM elements). The tool should then produce a default ORM file that looks as Craig describes. An empty element is going to be a source of confusion. I've looked at all the examples in your email, and lined them up with the spec and I agree with Craig's interpretations. Keep up the good work, and Go JPOX! -geoff Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: Detachment contract
> The jdoDetachedState is an Object[ ] that consists
> of:
>
> {
> Object objectId,
> Object version,
> BitSet loadedFields,
> BitSet modifiedFields
> }
I also think it would be a nice improvement to make
loadedFields and modifiedFields accessible and useable
for non-detached classes. It's in good keeping with
Law of Demeter to keep this information as close to
the source as possible, instead of forcing the
StateManager to track it.
We'd need to add jdoGetLoadedFields() and
jdoGetModifiedFields().
Or is there some reason this wouldn't work or doesn't
make sense?
-geoff
> The enhancer implements
>
> Object jdoGetVersion() {
>if (jdoStateManager != null) return
> jdoStateManager.getVersion(this);
>try {
> return (jdoDetachedState ==
> null)?null:jdoDetachedState[1];
>} catch (Exception ex) {
> throw new JDOFatalInternalException(msg.msg
> ("EXC_IllegalDetachedState", ex);
>}
> }
>
> Object jdoGetObjectId() {
>if (jdoStateManager != null) return
> jdoStateManager.getObjectId
> (this);
>try {
> return (jdoDetachedState ==
> null)?null:jdoDetachedState[0];
>} catch (Exception ex) {
> throw new JDOFatalInternalException(msg.msg
> ("EXC_IllegalDetachedState", ex);
>}
> }
>
> PersistenceManager flags determine the behavior for
> detachment,
> regardless of whether the detachment is due to
> serialization or
> explicit detachCopy.
>
> get/setDetachmentOptions(int flags). The standard
> values are:
> public final static DETACH_LOAD_FIELDS
> public final static DETACH_UNLOAD_FIELDS
>
> The LOAD_FIELDS flag specifies that the fetch plan
> in effect at the
> time the object is detached determines the fields
> that must be loaded
> (fetched from the datastore and marked as loaded) in
> the detached
> instances. If this flag is not set, then the fields
> in the fetch plan
> might be loaded or not depending on when the
> instances were fetched.
>
> The UNLOAD_FIELDS flag specifies that the fetch plan
> in effect at the
> time the object is detached determines the fields
> that must be
> unloaded (set to their Java default values and
> marked as not loaded)
> in the detached instances. If this flag is not set,
> then the fields
> not in the fetch plan might be loaded or not
> depending on when the
> instances were fetched.
>
> Detachable classes that implement writeObject and
> readObject pose a
> problem. The JVM standard serialization will include
> the
> jdoDetachedState field because it is known to the
> VM. If the
> writeObject delegates to the standard, this is fine.
> If not, the
> jdoDetachedState field will not be written. So the
> enhancer checks
> that the user's writeObject delegates to the
> out.defaultWriteObject()
> and if it does not, inserts a call to write the
> jdoDetachedState
> instance ahead of the rest of the object in the
> output stream. The
> readObject method is similarly changed to read the
> state of the
> jdoDetachedState field.
>
> Similarly, if the class implements Externalizable,
> the enhancer adds
> the code to the readExternal and writeExternal
> methods to handle the
> jdoDetachedState field.
>
> The jdoFlags value DETACHED is not used and will be
> removed from the
> interface.
>
> Craig Russell
> Architect, Sun Java Enterprise System
> http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
>
>
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
org.apache.jdo.tck.api.instancecallbacks.CallingJdoPreclear
tck11 test: org.apache.jdo.tck.api.instancecallbacks.CallingJdoPreclear in InstanceCallbackClass.jdoPreClear the following line causes a NullPointerException because children is null: ... numberOfChildren[intValue] = children.size(); ... children is not in the default-fetch-group and never gets loaded within the transaction for the PC "primaryObj". The "touchFields" method never touches primaryObj.children, thus it remains null, having been set null in the transition to HOLLOW caused by the prior commit. Because jdoPreClear is not modified by the enhancer, children does not get loaded when jdoPreClear is called and the NullPointerException is thrown. This could be fixed by modifying the "package.jdo" meta-data to add default-fetch-group="true" for the field 'children'. Please review and let me know if you agree. -geoff --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, > > We will have our regular meeting Friday, June 17 at > 9 am PST to discuss > JDO TCK issues and status. > > Dial-in numbers are: > > 866 230-6968 294-0479# > International: +1 865 544-7856 > > Agenda: > > Test status (Michael W., Michelle) > TestRunner status(Michelle) > JPOX fixes/issues (Erik) > Apache account for Michael W (Craig) > Double-check locking in the PMF (Martin) no change > Detached objects (Matthew) no change > Other issues and status (any and all) > > Action Items from weeks past: > > [Jun 10 2005] AI: Everyone read the wiki discussion > re: test runner that > Michelle has updated.. > <> > > [Jun 10 2005] Michelle has updated the wiki page > TestRunner description. > Comments are eagerly sought. > > [Jun 3 2005] AI: Michael file a JIRA for upgrading > the enhancer tests to > JDO 2. > > AI XML Schema (Brian T) no change. > > AI JDO API release on ibiblio (Brian T) no change. > > [Jun 3 2005] AI: Michelle add CompletenessTest to > "all tests" list. Done. > > [Jun 3 2005] AI: Craig file a JIRA on current > errors. > > [May 20 2005] AI: Craig file JIRA bug and fix this. > Can test cases rely > on JDOHelper for state interrogation of > non-binary-compatibility > classes? Yes, but the JDO 2.0 JDOImplHelper class > has not implemented > the functionality yet. > > [April 15 2005] AI Brian Topping will update the > wiki to tell how to > access our releases area. > > [April 15 2005] AI Brian Topping will do the maven > goal for creating and > uploading the snapshots. He will create a directory > parallel to trunk > called "releases" and put the snapshots there. > > [April 15 2005] AI Matthew will create a directory > in the > tck.api.persistencemanager called detach in which he > will have complete > freedom to implement the assertions in the detach > section of the > specification. > > [April 22 2005] AI Craig will resolve what happens > if an application > identity field is changed while the object is > detached. > > [April 22 2005] AI Craig will resolve the > serialization contract for a > Detachable class so that implementations > interoperate. > > [May 13 2005] AI Brian Topping will implement > pushing SNAPSHOT builds of > the project to ibiblio. > > [May 13 2005] AI Brian Topping will arrange for > automated nightly builds. > > [May 13 2005] AI Martin Zaun will investigate JSR > 294 (Java 5) to see > impact on enhancer. > > [May 13 2005] AI Geoff try to get tck20 to run with > JDOMax. > > [May 20 2005] AI Craig to define the JCP > distributions and see if maven > can help. > > -- Michelle > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
CallingJdoPreclear
Ahh, I see now that retrieve is called, which should load in all the fields of the PC. I am presently only loading the DFG when retrieve is called, so the bug is in JDOMax. -geoff __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Question on TCK11
The test in question used DatastoreIdentity. you said: "The classes in question have a set of fields that uniquely form an *application identity*" and I'm just saying no, they don't form an *application identity*, because this test doesn't use application identity. It uses Datastore Identity. Ho hum, I guess I'm just grumpy because I didn't expect the Apache TCK to be so different from the Sun TCK. -geoff --- Craig Russell <[EMAIL PROTECTED]> wrote: > Hi Geoff, > > It sounds like you are confusing application > equality with JDO > identity, which are two separate concepts. > > JVM has identity that you test with a == b. > > Applications have equality that you test with > a.equals(b). > > JDO has identity that you test with > a.getObjectId().equals(b.getObjectId()). > > Three different concepts. > > Craig > > On May 21, 2005, at 6:37 PM, Geoff hendrey wrote: > > > > >> The classes in question have a set of fields that > >> uniquely form an > >> application identity, and hashCode and equals use > >> these fields. I don't > >> see the issue. > > > > DatastoreIdentity is used, so no, they don't form > an > > application identity. > > > > -geoff > > > > > > > > > > > > > > > > > > Discover Yahoo! > > Find restaurants, movies, travel and more fun for > the weekend. Check > > it out! > > http://discover.yahoo.com/weekend.html > > > > > Craig Russell > Architect, Sun Java Enterprise System > http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/
Re: Question on TCK11
> The classes in question have a set of fields that > uniquely form an > application identity, and hashCode and equals use > these fields. I don't > see the issue. DatastoreIdentity is used, so no, they don't form an application identity. -geoff Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html
Question on TCK11
Department.hashCode method is using a persistent field to compute the value of the hashcode, in TCK11. Note that in the Sun version of the TCK, which JDOMax passes, hashCode is NOT overidden for Department. I think it is wrong to override hashCode and equals for any class using datastore identity. This was the subject of 35 or so emails on the experts group, and this was the position espoused by Craig. Craig laid down the law: "If you don't have a set of fields that uniquely form an application identity, then you should not implement equals. You *should* delegate to Object.equals" Please let me know if an implementation is expected to handle cases when the user overides equals and hashCode for datastore identity? Certainly, JDOMax does NOT, and is failing a good bit of the Apache TCK11 because of it! -geoff __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
Re: JDO TCK Conference Call Friday, May 20, 9 am PST
Unfortunately I can't join in tomorrow. --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, > > We will have our regular meeting Friday, May 20 at 9 > am PST to discuss > JDO TCK issues and status. > > Dial-in numbers are: > > 866 230-6968 294-0479# > International: +1 865 544-7856 > > Agenda: > > Test status (Michelle) > Test cleanup fix (Michael W.) > What is test/conf/JDOTCKTestCases.list for? (Michael > B.) > Detached objects (Matthew) > Build dependency on cvs (Geoff) > Apache accounts for Matthew and Eric (Craig) > XML Schema (Brian T) > JDO API release on ibiblio (Brian T) > Other issues and status (any and all) > > -- Michelle > Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
The dependency on CVS is bad. I use subversion, and had to go off and download 2 different CVS clients, and both failed when maven tried to call them. I had to grab the code through winCVS, and wound up updating fromn the head instead of the proper tag. All this would go away if you would simply toss all the dependency jars into a maven repo and ship it with the project. You can set the relative repo location through a standard maven property. -geoff --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > This is now JDO-51, assigned to me. > > -- Michelle > > Michael Bouschen wrote: > > > Hi Michelle, > > > > yes, we need to describe the dependencies in the > README.txt. I propose > > the following build order: > > JDO1: api11, btree, ri11, tck11 > > JDO2: api20, tck20 > > > > Another alternative is using the multiproject > support of maven. You > > can call 'maven -Dgoal=build multiproject:goal' in > the directory > > trunk. Then maven looks at all the subprojects and > calculates a > > dependency graph using the specified dependencies > in the project.xml > > file. It then executes the goal build in all the > subprojects in the > > order of the calculated dependencies. The only > downside is that it > > does it for all the subprojects, so for the jdo1 > and jdo2 subprojects. > > > > Regards Michael > > > >> Hi, Geoff, > >> > >> All you need to do is check out the jdo project > and build the > >> subprojects in the correct order. You will get > six subprojects from > >> the jdo subversion repository: > >> > >> api11 > >> api20 > >> btree > >> ri11 > >> tck11 > >> tck20 > >> > >> To get the btree jar in your local repository > with the appropriate > >> name you just do "maven build" in > jdo/trunk/btree. > >> > >> It seems that we need to add information to > README.txt regarding > >> dependencies in building the subprojects, e.g. > you must build btree > >> before building tck11, ... > >> > >> Hope this helps, > >> Michelle > >> > >> Geoff hendrey wrote: > >> > >>> I'm trying to run the tck11 "enhance" goal. > >>> > >>> There is a dependency on jdo-btree-SNAPSHOT. > >>> When I try to execute the three CVS commands to > get > >>> the code, I succesfully get > >>> org\netbeans\mdr\persistence package, but the > >>> btreeimpl subpackage appears to not exist. If I > create > >>> the btreeimpl subpackage by hand, and execute > the cvs > >>> update, it zaps the btreeimpl folder, so I take > it it > >>> really does not exist in the cvs repository. > Thus, I > >>> am stuck. > >>> > >>> In my opinion, it would be a good idea to ship a > >>> prebuilt, local maven repository, configured > with all > >>> the jars. Or at least make this maven repository > >>> available for download. Then you can set your > >>> project.properties to simply point to a local > >>> repository. Actually relying on maven to > download jars > >>> and/or source almost never works, especially if > you > >>> specify head snapshot as opposed to a specific > >>> revision. > >>> > >>> my $0.02. > >>> > >>> So can somebody send me the > jdo-btree-SNAPSHOT.jar? > >>> > >>> -geoff > >>> > >>> > >>> > >>> --- Michelle Caisse <[EMAIL PROTECTED]> > wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> We will have our regular meeting Friday, May 13 > at > >>>> 9 am PST to discuss JDO TCK issues and status. > >>>> > >>>> Dial-in numbers are: > >>>> > >>>> 866 230-6968 294-0479# > >>>> International: +1 865 544-7856 > >>>> > >>>> Agenda: > >>>> > >>>> XML Schema (Brian T - specifics on orm dtd > issues, > >>>> Craig - dtd issues fixed?) > >>>> JDO API release on ibiblio (Brian T, Craig) > >>>> Detached objects (Matthew) > >>>> Test development status (Michelle) > >>>> Apache nightly builds (Brian) > >>>> Other issues and status (any and all) > >>>> > >>>> -- Michelle > >>>> > >>>> > >>> > >>> > >>> > >>> > >>>Yahoo! Mail > >>> Stay connected, organized, and protected. Take > the tour: > >>> http://tour.mail.yahoo.com/mailtour.html > >>> > >>> > >>> > >> > >> > > > > > > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
The ideal thing would be if commenting out a test in JDOTCKTestCases had the expected behavior. I figured that allTests.list was there for the purpose of cresating summary stats, so it could tell you that 10 tests were excluded or something like that. But I noticed that all the tests I commented out in JDOTCKTestCases get run anyways. --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, Geoff, > > I'm not really sure of the purpose of > JDOTCKTestCases.list. I hope > Michael can explain this. In fact if you run the > runtck or runtck.jdori > targets, they read allTests.list. When I want to > run a shorter set, I > keep a copy of allTests.list and delete entries to > run only the set that > I want. Do we need to have an exclude feature like > JavaTest? > > -- Michelle > > Geoff hendrey wrote: > > >OK, so am am able to run the tck11 against JDOMax. > > > >There are two files in test/conf that seem to > >enumerate the test cases: allTests.list and > >JDOTCKTestCases.list. > > > >Why 2 files? > > > >What is the recommended way to have an "exclude > list" > >(JavaTest parlance). I'm assuming I just comment > the > >tests out in JDOTCKTestCases.list and leave > >allTests.list untouched. That right? > > > >-geoff > > > > > > > >--- Michelle Caisse <[EMAIL PROTECTED]> > wrote: > > > > > > > >>Hi, Geoff, > >> > >>All you need to do is check out the jdo project > and > >>build the > >>subprojects in the correct order. You will get > six > >>subprojects from the > >>jdo subversion repository: > >> > >>api11 > >>api20 > >>btree > >>ri11 > >>tck11 > >>tck20 > >> > >>To get the btree jar in your local repository with > >>the appropriate name > >>you just do "maven build" in jdo/trunk/btree. > >> > >>It seems that we need to add information to > >>README.txt regarding > >>dependencies in building the subprojects, e.g. you > >>must build btree > >>before building tck11, ... > >> > >>Hope this helps, > >>Michelle > >> > >>Geoff hendrey wrote: > >> > >> > >> > >>>I'm trying to run the tck11 "enhance" goal. > >>> > >>>There is a dependency on jdo-btree-SNAPSHOT. > >>> > >>>When I try to execute the three CVS commands to > get > >>>the code, I succesfully get > >>>org\netbeans\mdr\persistence package, but the > >>>btreeimpl subpackage appears to not exist. If I > >>> > >>> > >>create > >> > >> > >>>the btreeimpl subpackage by hand, and execute the > >>> > >>> > >>cvs > >> > >> > >>>update, it zaps the btreeimpl folder, so I take > it > >>> > >>> > >>it > >> > >> > >>>really does not exist in the cvs repository. > Thus, > >>> > >>> > >>I > >> > >> > >>>am stuck. > >>> > >>>In my opinion, it would be a good idea to ship a > >>>prebuilt, local maven repository, configured with > >>> > >>> > >>all > >> > >> > >>>the jars. Or at least make this maven repository > >>>available for download. Then you can set your > >>>project.properties to simply point to a local > >>>repository. Actually relying on maven to download > >>> > >>> > >>jars > >> > >> > >>>and/or source almost never works, especially if > you > >>>specify head snapshot as opposed to a specific > >>>revision. > >>> > >>>my $0.02. > >>> > >>>So can somebody send me the > jdo-btree-SNAPSHOT.jar? > >>> > >>>-geoff > >>> > >>> > >>> > >>>--- Michelle Caisse <[EMAIL PROTECTED]> > >>> > >>> > >>wrote: > >> > >> > >>> > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>We will have our regular meeting Friday, May 13 > >>>> > >>>> > >>at > >> > >> > >>>>9 am PST to discuss > >>>>JDO TCK issues and status. > >>>> > >>>>Dial-in numbers are: > >>>> > >>>>866 230-6968 294-0479# > >>>>International: +1 865 544-7856 > >>>> > >>>>Agenda: > >>>> > >>>>XML Schema (Brian T - specifics on orm dtd > issues, > >>>>Craig - dtd issues > >>>>fixed?) > >>>>JDO API release on ibiblio (Brian T, Craig) > >>>>Detached objects (Matthew) > >>>>Test development status (Michelle) > >>>>Apache nightly builds (Brian) > >>>>Other issues and status (any and all) > >>>> > >>>>-- Michelle > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>>Yahoo! Mail > >>>Stay connected, organized, and protected. Take > the > >>> > >>> > >>tour: > >> > >> > >>>http://tour.mail.yahoo.com/mailtour.html > >>> > >>> > >>> > >>> > >>> > >> > === message truncated === __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
OK, so am am able to run the tck11 against JDOMax. There are two files in test/conf that seem to enumerate the test cases: allTests.list and JDOTCKTestCases.list. Why 2 files? What is the recommended way to have an "exclude list" (JavaTest parlance). I'm assuming I just comment the tests out in JDOTCKTestCases.list and leave allTests.list untouched. That right? -geoff --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, Geoff, > > All you need to do is check out the jdo project and > build the > subprojects in the correct order. You will get six > subprojects from the > jdo subversion repository: > > api11 > api20 > btree > ri11 > tck11 > tck20 > > To get the btree jar in your local repository with > the appropriate name > you just do "maven build" in jdo/trunk/btree. > > It seems that we need to add information to > README.txt regarding > dependencies in building the subprojects, e.g. you > must build btree > before building tck11, ... > > Hope this helps, > Michelle > > Geoff hendrey wrote: > > >I'm trying to run the tck11 "enhance" goal. > > > >There is a dependency on jdo-btree-SNAPSHOT. > > > >When I try to execute the three CVS commands to get > >the code, I succesfully get > >org\netbeans\mdr\persistence package, but the > >btreeimpl subpackage appears to not exist. If I > create > >the btreeimpl subpackage by hand, and execute the > cvs > >update, it zaps the btreeimpl folder, so I take it > it > >really does not exist in the cvs repository. Thus, > I > >am stuck. > > > >In my opinion, it would be a good idea to ship a > >prebuilt, local maven repository, configured with > all > >the jars. Or at least make this maven repository > >available for download. Then you can set your > >project.properties to simply point to a local > >repository. Actually relying on maven to download > jars > >and/or source almost never works, especially if you > >specify head snapshot as opposed to a specific > >revision. > > > >my $0.02. > > > >So can somebody send me the jdo-btree-SNAPSHOT.jar? > > > >-geoff > > > > > > > >--- Michelle Caisse <[EMAIL PROTECTED]> > wrote: > > > > > >>Hi, > >> > >>We will have our regular meeting Friday, May 13 > at > >>9 am PST to discuss > >>JDO TCK issues and status. > >> > >>Dial-in numbers are: > >> > >>866 230-6968 294-0479# > >>International: +1 865 544-7856 > >> > >>Agenda: > >> > >>XML Schema (Brian T - specifics on orm dtd issues, > >>Craig - dtd issues > >>fixed?) > >>JDO API release on ibiblio (Brian T, Craig) > >>Detached objects (Matthew) > >>Test development status (Michelle) > >>Apache nightly builds (Brian) > >>Other issues and status (any and all) > >> > >>-- Michelle > >> > >> > >> > > > > > > > >Yahoo! Mail > >Stay connected, organized, and protected. Take the > tour: > >http://tour.mail.yahoo.com/mailtour.html > > > > > > > > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
my old TCK notes
These are notes I gathered from the last version of
the TCK I ran (not what I just got from Apache, but
maybe some of the problems remain, we'll see). These
are notes on the test source code itself. I'm not
looking for any feedback on this, jut thought I would
toss it out there.
Package: com.sun.jdotck.api.PersistenceManager
==
[test class = GetObjectIdClass]
contains hardcoded reference to RI's OID class.
c1.getName().equals("com.sun.jdori.fostore.OID")
This causes non-RI to wrongly fail.
[test class =
ConcurrentPersistenceManagerSameClasses]
Does not properly cleanup PCPoint and PCRect
objects. COnsequently, if the
test is run more than once, it fails the second
time. The reason for
failure is because the "findPoint" method issues a
jdo query, and uses
the first object returned by the query's iterator.
However, there may
be multiple objects in the iterator. The test then
goes on to compare the
JAVA identity of said first object with the JAVA
identity of the object
made persistent earlier in the transaction. This
leads to a failure with
a message:
"Found PCPoint: 110, 120
Expected: 110, 120"
This test would be fixed by deleting all objects
matching the query BEFORE
doing the first insert, or by changing the test
comparison from JAVA
identity to 110==p11a.getX() && 120==p11a.getY()
[test = OneInstanceOfObjectPerPersistenceManager]
this test cannot be run twice in a row without
clearing the database. Query
findPoint (int x, int y) will simply find a point
from a previous run. Since
we're using datastore identity, the object
retrieved from the query will be
different since it has a different database pk.
this results in Failed.
"Assertion A5.4-2 failed; query results differ"
[test = RefreshSideEffects]
While not stricktly a bug, this test cannot be run
twice in a row from the
same JVM. This is because PersistenceCapable "n1"
is declared as static.
The second time the test is run,
"makePersistent(n1)" is called on a different
persistence manager, while n1 remains in the cache
of the first pm. This
is illegal. This problem also manifests itself in
all tests begining with
"Refresh".
Package: com.sun.jdotck.api.InstanceCallbacks
=
[test class = CallingJdoPreClear]
in InstanceCallbackClass.jdoPreClear the following
line causes a
NullPointerException because children is null:
...
numberOfChildren[intValue] = children.size();
...
children is not in the default-fetch-group and
never gets loaded within the
transaction for the PC "primaryObj". The
"touchFields" method never touches
primaryObj.children, thus it remains
null, having been set null in the transition to
HOLLOW caused by the prior
commit. Because jdoPreClear is not modified by the
enhancer, children does
not get loaded when jdoPreClear is called and the
NullPointerException is
thrown. This could be fixed by modifying the
"instanceCallbacks.jdo" meta-
data to add default-fetch-group="true" for the
field 'children'.
package: com.sun.jdotck.models.company
===
[test class = Company]
in constructor, parameter 'addr' is not assigned
to instance variable
'address'
address = address
should be changed to "this.address = addr;"
package: com.sun.jdotck.models.fieldtypes
===
[test class = TestFieldsOfObject]
The default value for Object0 is null. When the
test forces garbage
collection via System.gc(), the PC is garbage
collected. When the PC is
materialized from the datastore on getObjectById,
a new instance of the PC
is constructed. Because Object0 is not persistent,
val assumes null default
value. This causes a null pointer exception when
!val.equals(startValue)
is evaluated. The solution is to properly set the
value of isPersistent[0]
to false. This test incorrectly has set
isPersistent[0] to true. If the
value of isPersistent[0] is set to false, the
offending block of code is
correctly skiped and the null pointer avoided.
The same error will be caused for several
non-persistent fields.
All of the following indexes of isPersistent
should be false, not true:
0,16,36,52,72,88,108,124
[test class = TestFieldsOfSimpleInterface]
The problem is identical to that of
TestFieldsOfObject.
All of the following indexes of isPersistent
should be false, not true:
0,16,36,52,72,88,108,124
[test class = TestCollectionCollections]
Should not use Vector, since application is not
required to support
Collection or Set unless they reference a
HashSet. Causes a
ClassCastException to be thrown.
package: com.sun.jdotck.models.inheritance
===
[test class = Nonper
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
The CVS checkout was failing in the maven btree build target. Apparently I also failed to manually checkout the btree/impl package when I tried to do so manually with CVS. Because I was able to succesfully checkout the persistence parent package of impl, I concluded that the repo was messed up and was missing persistence/impl. I downloaded wincvs and gave it another shot. This time I was able to manually checkout the impl package. The maven checkout stuff still fails, but I've got the code, so it proceeeds to compile. Now I am getting some compiler errors, that look like I simply need to tell maven to enable assertions (java -ea). Here's an example of one of the errors: E:\apachetck\trunk\btree\mdr\src\org\netbeans\mdr\persistence\btreeimpl\btreesto rage\PrimaryIndex.java:53: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier assert serial>=firstMofIdSerial; ^ E:\apachetck\trunk\btree\mdr\src\org\netbeans\mdr\persistence\btreeimpl\btreesto rage\PrimaryIndex.java:53: ';' expected assert serial>=firstMofIdSerial; So if someone has a quick tip on how to get maven to enable assertions, that'd be great and I could keep going. I still think you should provide a static local maven repository with all the required jar files. -geoff --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, Geoff, > > All you need to do is check out the jdo project and > build the > subprojects in the correct order. You will get six > subprojects from the > jdo subversion repository: > > api11 > api20 > btree > ri11 > tck11 > tck20 > > To get the btree jar in your local repository with > the appropriate name > you just do "maven build" in jdo/trunk/btree. > > It seems that we need to add information to > README.txt regarding > dependencies in building the subprojects, e.g. you > must build btree > before building tck11, ... > > Hope this helps, > Michelle > > Geoff hendrey wrote: > > >I'm trying to run the tck11 "enhance" goal. > > > >There is a dependency on jdo-btree-SNAPSHOT. > > > >When I try to execute the three CVS commands to get > >the code, I succesfully get > >org\netbeans\mdr\persistence package, but the > >btreeimpl subpackage appears to not exist. If I > create > >the btreeimpl subpackage by hand, and execute the > cvs > >update, it zaps the btreeimpl folder, so I take it > it > >really does not exist in the cvs repository. Thus, > I > >am stuck. > > > >In my opinion, it would be a good idea to ship a > >prebuilt, local maven repository, configured with > all > >the jars. Or at least make this maven repository > >available for download. Then you can set your > >project.properties to simply point to a local > >repository. Actually relying on maven to download > jars > >and/or source almost never works, especially if you > >specify head snapshot as opposed to a specific > >revision. > > > >my $0.02. > > > >So can somebody send me the jdo-btree-SNAPSHOT.jar? > > > >-geoff > > > > > > > >--- Michelle Caisse <[EMAIL PROTECTED]> > wrote: > > > > > >>Hi, > >> > >>We will have our regular meeting Friday, May 13 > at > >>9 am PST to discuss > >>JDO TCK issues and status. > >> > >>Dial-in numbers are: > >> > >>866 230-6968 294-0479# > >>International: +1 865 544-7856 > >> > >>Agenda: > >> > >>XML Schema (Brian T - specifics on orm dtd issues, > >>Craig - dtd issues > >>fixed?) > >>JDO API release on ibiblio (Brian T, Craig) > >>Detached objects (Matthew) > >>Test development status (Michelle) > >>Apache nightly builds (Brian) > >>Other issues and status (any and all) > >> > >>-- Michelle > >> > >> > >> > > > > > > > >Yahoo! Mail > >Stay connected, organized, and protected. Take the > tour: > >http://tour.mail.yahoo.com/mailtour.html > > > > > > > > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
Never mind my question about the assertions. Now this: java:compile: [echo] Compiling to E:\apachetck\trunk\btree/target/classes [javac] Compiling 55 source files to E:\apachetck\trunk\btree\target\classes E:\apachetck\trunk\btree\mdr\src\org\netbeans\mdr\persistence\btreeimpl\btreeind ex\VarKeyPage.java:18: package org.openide does not exist import org.openide.ErrorManager; ^ E:\apachetck\trunk\btree\mdr\src\org\netbeans\mdr\persistence\btreeimpl\btreeind ex\VarKeyPage.java:177: cannot resolve symbol symbol : variable ErrorManager location: class org.netbeans.mdr.persistence.btreeimpl.btreeindex.VarKeyPage ErrorManager.getDefault().log(ErrorManager.EXCEPTION, msg); ^ E:\apachetck\trunk\btree\mdr\src\org\netbeans\mdr\persistence\btreeimpl\btreeind ex\VarKeyPage.java:177: cannot resolve symbol symbol : variable ErrorManager location: class org.netbeans.mdr.persistence.btreeimpl.btreeindex.VarKeyPage ErrorManager.getDefault().log(ErrorManager.EXCEPTION, msg); ^ 3 errors --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, Geoff, > > All you need to do is check out the jdo project and > build the > subprojects in the correct order. You will get six > subprojects from the > jdo subversion repository: > > api11 > api20 > btree > ri11 > tck11 > tck20 > > To get the btree jar in your local repository with > the appropriate name > you just do "maven build" in jdo/trunk/btree. > > It seems that we need to add information to > README.txt regarding > dependencies in building the subprojects, e.g. you > must build btree > before building tck11, ... > > Hope this helps, > Michelle > > Geoff hendrey wrote: > > >I'm trying to run the tck11 "enhance" goal. > > > >There is a dependency on jdo-btree-SNAPSHOT. > > > >When I try to execute the three CVS commands to get > >the code, I succesfully get > >org\netbeans\mdr\persistence package, but the > >btreeimpl subpackage appears to not exist. If I > create > >the btreeimpl subpackage by hand, and execute the > cvs > >update, it zaps the btreeimpl folder, so I take it > it > >really does not exist in the cvs repository. Thus, > I > >am stuck. > > > >In my opinion, it would be a good idea to ship a > >prebuilt, local maven repository, configured with > all > >the jars. Or at least make this maven repository > >available for download. Then you can set your > >project.properties to simply point to a local > >repository. Actually relying on maven to download > jars > >and/or source almost never works, especially if you > >specify head snapshot as opposed to a specific > >revision. > > > >my $0.02. > > > >So can somebody send me the jdo-btree-SNAPSHOT.jar? > > > >-geoff > > > > > > > >--- Michelle Caisse <[EMAIL PROTECTED]> > wrote: > > > > > >>Hi, > >> > >>We will have our regular meeting Friday, May 13 > at > >>9 am PST to discuss > >>JDO TCK issues and status. > >> > >>Dial-in numbers are: > >> > >>866 230-6968 294-0479# > >>International: +1 865 544-7856 > >> > >>Agenda: > >> > >>XML Schema (Brian T - specifics on orm dtd issues, > >>Craig - dtd issues > >>fixed?) > >>JDO API release on ibiblio (Brian T, Craig) > >>Detached objects (Matthew) > >>Test development status (Michelle) > >>Apache nightly builds (Brian) > >>Other issues and status (any and all) > >> > >>-- Michelle > >> > >> > >> > > > > > > > >Yahoo! Mail > >Stay connected, organized, and protected. Take the > tour: > >http://tour.mail.yahoo.com/mailtour.html > > > > > > > > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
Re: JDO TCK Conference Call Friday, May 13, 9 am PST
I'm trying to run the tck11 "enhance" goal. There is a dependency on jdo-btree-SNAPSHOT. When I try to execute the three CVS commands to get the code, I succesfully get org\netbeans\mdr\persistence package, but the btreeimpl subpackage appears to not exist. If I create the btreeimpl subpackage by hand, and execute the cvs update, it zaps the btreeimpl folder, so I take it it really does not exist in the cvs repository. Thus, I am stuck. In my opinion, it would be a good idea to ship a prebuilt, local maven repository, configured with all the jars. Or at least make this maven repository available for download. Then you can set your project.properties to simply point to a local repository. Actually relying on maven to download jars and/or source almost never works, especially if you specify head snapshot as opposed to a specific revision. my $0.02. So can somebody send me the jdo-btree-SNAPSHOT.jar? -geoff --- Michelle Caisse <[EMAIL PROTECTED]> wrote: > Hi, > > We will have our regular meeting Friday, May 13 at > 9 am PST to discuss > JDO TCK issues and status. > > Dial-in numbers are: > > 866 230-6968 294-0479# > International: +1 865 544-7856 > > Agenda: > > XML Schema (Brian T - specifics on orm dtd issues, > Craig - dtd issues > fixed?) > JDO API release on ibiblio (Brian T, Craig) > Detached objects (Matthew) > Test development status (Michelle) > Apache nightly builds (Brian) > Other issues and status (any and all) > > -- Michelle > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
RE: Surrogate keys and application identity
So far Wes, Eric, Bin, and I seem to support the idea of renaming the "primary-key" attribute of .jdo metadata to "identity". I really think we should do this, and change all references in the documentation to refer to "identity field(s)" rather than "primary key fields". -geoff --- Eric Samson <[EMAIL PROTECTED]> wrote: > Geoff > > I agree that would be better. > > If we are going in that direction, I would also like > to rename "Datastore > Identity" to something that better represents what > it is: "Transparent > Identity". > > Then "Application Identity" could become "Explicit > Identity", with sub-types > like "Application Identity" (really managed by the > application that is > responsible to supply identity values), "Datastore > Identity" (relying on a > specific datastore features for identity, like > sequences or auto-incrmented > columns)... > > But I don't know if we can really change all these > things now, with all the > JDO users we have. > > Best Regards > .: > Eric Samson, xcalia > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 16 février 2005 19:20 > À : Craig Russell > Cc : JDO Expert Group; jdo-dev@db.apache.org > Objet : Re: Surrogate keys and application identity > > Personally I think we *should* change the spec. The > use of "primary key" to > describe fields in a Java Object model was a poor > choice. I have grepped the > doc too for "primary key", and as you pointed out, > it occurs in a handful of > places. Certainly small enough to edit in 15 minutes > or so. I'll happily do > it myself and send you redlines if you like. > > I think all places in the document where it says > "primary key field" (or the > like) should be changed to "identity field". > Furthermore, I think the .jdo > metadata should change the "primary-key" attribute > to "identity". It just > doesn't make sense to introduce the notion of > primary key into a spec that > is supposed to be independent of the datastore. > > This would completely disambiguate "primary key". > And we would be free to > use the term "primary key" in the ORM to describe > ... a PRIMARY KEY > (shockingly). I > mean, doesn't it seem silly that we are hamstrung > from being able to say in an XML > format for ORM?? > > -geoff > > > > --- Craig Russell <[EMAIL PROTECTED]> wrote: > > > Hi Geoff, > > > > On Feb 12, 2005, at 8:22 PM, Geoff hendrey wrote: > > > > > I think we've reached agreement on another issue > > as > > > well. That is, changing to > . > > > > I'm not sold on this yet. > > > > We have defined the concept of primary key in the > object model and > > enhancer. "Application identity is often called > primary key"; "An > > application attempt to change the identity of an > instance (by writing > > a primary key field)"; "Application developers > should take into > > account that changing primary key values changes > the identity of the > > instance in the datastore"; "A JDO implementation > is required to > > support either or both of application (primary > key) identity or > > datastore identity"; "the names of the non-static > fields in the > > ObjectId class must include the names of the > primary key fields in the > > JDO class"; "the equals() and hashCode() methods > of the ObjectId class > > must use the value(s) of all the fields > corresponding to the primary > > key fields in the JDO class"; "A primary key > identity is associated > > with a specific set of fields"; "[a hollow > instance] transitions to > > persistent-clean if a read access is made to any > persistent field > > other than one of the primary key fields"; "The > "none" fetch group > > contains only primary key fields". > > > > You get the point, which is that I don't want to > go through the spec > > and adapt all references that currently refer to > primary key and > > change them to something else. > > > > How about a different approach? > > > > You could use the element in > a class that is > > defined to use application identity. This would > not be required, but > > would be permitted. Your implementation would > define
Re: Surrogate keys and application identity
Personally I think we *should* change the spec. The use of "primary key" to describe fields in a Java Object model was a poor choice. I have grepped the doc too for "primary key", and as you pointed out, it occurs in a handful of places. Certainly small enough to edit in 15 minutes or so. I'll happily do it myself and send you redlines if you like. I think all places in the document where it says "primary key field" (or the like) should be changed to "identity field". Furthermore, I think the .jdo metadata should change the "primary-key" attribute to "identity". It just doesn't make sense to introduce the notion of primary key into a spec that is supposed to be independent of the datastore. This would completely disambiguate "primary key". And we would be free to use the term "primary key" in the ORM to describe ... a PRIMARY KEY (shockingly). I mean, doesn't it seem silly that we are hamstrung from being able to say in an XML format for ORM?? -geoff --- Craig Russell <[EMAIL PROTECTED]> wrote: > Hi Geoff, > > On Feb 12, 2005, at 8:22 PM, Geoff hendrey wrote: > > > I think we've reached agreement on another issue > as > > well. That is, changing to > > . > > I'm not sold on this yet. > > We have defined the concept of primary key in the > object model and > enhancer. "Application identity is often called > primary key"; "An > application attempt to change the identity of an > instance (by writing a > primary key field)"; "Application developers should > take into account > that changing primary key values changes the > identity of the instance > in the datastore"; "A JDO implementation is required > to support either > or both of application (primary key) identity or > datastore identity"; > "the names of the non-static fields in the ObjectId > class must include > the names of the primary key fields in the JDO > class"; "the equals() > and hashCode() methods of the ObjectId class must > use the value(s) of > all the fields corresponding to the primary key > fields in the JDO > class"; "A primary key identity is associated with a > specific set of > fields"; "[a hollow instance] transitions to > persistent-clean if a read > access is made to any persistent field other than > one of the primary > key fields"; "The "none" fetch group contains only > primary key fields". > > You get the point, which is that I don't want to go > through the spec > and adapt all references that currently refer to > primary key and change > them to something else. > > How about a different approach? > > You could use the element in a > class that is > defined to use application identity. This would not > be required, but > would be permitted. Your implementation would define > the surrogate key > using the definition, instead > of defining the > primary key columns using the application identity > key fields. > > Craig > > > > > -geoff > > > > --- Craig Russell <[EMAIL PROTECTED]> wrote: > > > >> Javadogs, > >> > >> I think I've captured this proposal in the > attached > >> specification > >> update. > >> > >> I plan to include this in the reconsideration > Public > >> Draft. > >> > >> > >> void retrieve(Object pc); > >> void retrieve(Object pc, boolean FGOnly); > >> void retrieveAll(Collection pcs); > >> void retrieveAll(Collection pcs, boolean FGOnly); > >> void retrieveAll(Object[] pcs); > >> void retrieveAll(Object[] pcs, boolean FGOnly); > >> These methods request the PersistenceManager to > load > >> all persistent > >> fields into the parameter instances. Subsequent > to > >> this call, the > >> application might call makeTransient on the > >> parameter instances, and > >> the fields can no longer be touched by the > >> PersistenceManager. The > >> PersistenceManager might also retrieve related > >> instances according to > >> the current fetch plan or a vendor-specific > pre-read > >> policy (not > >> specified by JDO). > >> > >> If the FGOnly parameter is true, and the fetch > plan > >> has not been > >> modified from its default setting (see 12.7.1), > then > >> this is a hint to > >> the implementation that only the fields in the > >> current fetch group need > >> to
