Re: JDO 2.1 specification draft can be reviewed...

[Craig L Russell]

I've opened https://issues.apache.org/jira/browse/JDO-538 for this issue.

Thanks,

Craig

On Aug 4, 2007, at 8:00 PM, cbeams wrote:

Craig, all




11.6, "Optional Feature Support":

The current draft specifies the signature

        Collection supportedOptions();

then continues to read

        "This method returns a Collection of String [...]"

This suggests that the signature should be

        Collection<String> supportedOptions();



14.6.1, "Query Execution"

I suggest we eliminate

        Object execute(Object p1);
        Object execute(Object p1, Object p2);
        Object execute(Object p1, Object p2, Object p3);

and deprecate

        Object executeWithArray(Object[] parameters);

in favor of a newly added

        Object execute(Object... parameters);





        Object execute();
        Object execute(Object... parameters);
        Object executeWithMap(Map parameters);





        Object execute();



and deprecate

        Object executeWithMap(Map params);

in favor of a new

        Object execute(Map params);





        Object execute(Object... params);
        Object execute(Map params);






14.8, "Deletion by Query":



        long deletePersistentAll(Object... params);
        long deletePersistentAll(Map params);

...



Thanks,

- Chris Beams

Several suggestions relating to evolving the API in support of Java5 features: This new method would seamlessly support any existing calls to the three eliminated methods, and is a proper replacement for executeWithArray(). This would would leave us with three (non-deprecated) execution methods off the Query interface: A slightly more radical approach to this evolution would have us also eliminate because the new varargs method can by definition support calls without arguments, because Java can disambiguate between calls to execute(Object... params) and execute(Map params) just fine. This is predecated by the assumption that it would never be valid to pass a Map instance as a first-class query parameter. That might be a faulty assumption, it might also just be confusing. If all these changes were made, we'd be left with an execution API consisting of just two methods: This is, I believe, technically favorable and cleaner, but technical considerations are not the only valid ones. Leaving the no-arg execute() might be friendly to folks that don't understand varargs, etc. The rationale used above for paring down Query's execute methods could also be applied to Query's deletePersistentAll methods. It would be legal and Java5-ish to eliminate the no-arg deletePersistentAll method and reduce the API down to: There's a number of other places in the spec changes like the ones mentioned here could be made, but I might be getting ahead of myself :-) I'll await comments before touching on anything else.

From: Craig L Russell <[EMAIL PROTECTED]>
Date: August 3, 2007 7:04:52 PM PDT

Subject: JDO 2.1 specification draft can be reviewed...


at http://db.apache.org/jdo/documentation.html

Check it out, and send comments...

Craig Russell

To: Apache JDO project <jdo-dev@db.apache.org>, JDO Expert Group <[EMAIL PROTECTED]> Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

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!

smime.p7s
Description: S/MIME cryptographic signature