db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-538) Make more JDO APIs generic
Date Thu, 04 Oct 2007 00:46:57 GMT

    [ https://issues.apache.org/jira/browse/JDO-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532306
] 

Craig Russell commented on JDO-538:
-----------------------------------

Just one more comment. Variable-arity only works if the variable part is the last argument.
So we either have to reorder the arguments or just not modify the signature for the methods
with extra arguments. So we either:

1. Add new signatures, e.g.
     void makeTransientAll (boolean useFetchPlan, Object... pcs); 
    void makeTransientAll (boolean useFetchPlan, Object... pcs); 
    void retrieveAll (boolean useFetchPlan, Object... pcs); 
2. Don't change the signatures for these methods:
    Object[] getObjectsById (Object[] oids, boolean validate); 
    void makeTransientAll (Object[] pcs, boolean useFetchPlan); 
    void retrieveAll (Object[] pcs, boolean useFetchPlan); 

Any preferences?

> Make more JDO APIs generic
> --------------------------
>
>                 Key: JDO-538
>                 URL: https://issues.apache.org/jira/browse/JDO-538
>             Project: JDO
>          Issue Type: Improvement
>          Components: api2
>    Affects Versions: JDO 2 final
>            Reporter: Chris Beams
>            Assignee: Craig Russell
>             Fix For: JDO 2 maintenance release 1
>
>         Attachments: jdo-538.patch
>
>
> Several suggestions relating to evolving the API in support of Java5 features:
> 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);
> 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:
> 	Object execute();
> 	Object execute(Object... parameters);
> 	Object executeWithMap(Map parameters);
> A slightly more radical approach to this evolution would have us also eliminate
> 	Object execute();
> because the new varargs method can by definition support calls without arguments,
> and deprecate
> 	Object executeWithMap(Map params);
> in favor of a new
> 	Object execute(Map params);
> 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:
> 	Object execute(Object... params);
> 	Object execute(Map params);
> 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.
> 14.8, "Deletion by Query":
> 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:
> 	long deletePersistentAll(Object... params);
> 	long deletePersistentAll(Map params);
> ...
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message