Having an abstraction for communicating status would be a cleaner approach. As
it allows us to extend the functionality if required in future.
For Example:
Lets say we are executing executeUpdate in multithreaded env. then we can
provide methods to check the status of the update. (running or done).
Also rather than having methods returning int I think we should return a
collection of Affected Rows.
And rather than having multiple methods for insert/delete/update just have a
single method returning the affected rows.
I think making so will make the API simpler yet functional.
>>> public interface UpdateStatus {
>>> public <List or Collection> getAffectedRows(); or just use getRows()
>>> }
-RS
On 10-Aug-2013, at 10:09 PM, Kasper Sørensen <[email protected]>
wrote:
> My experience with returning something like an
> int/String/other-simple-type is that it seems to fit the purpose at
> first, but then someone asks "couldn't we also get the status of
> [something], too?" ... and then you regret not encapsulating the
> return value so that you could just add another getter on it.
>
> 2013/8/10 Henry Saputra <[email protected]>:
>> We could just make the executeUpdate just return number of elements
>> affected similar to relational databases.
>>
>> It would be simpler and serve similar purpose.
>>
>> - Henry
>>
>>
>> On Fri, Aug 9, 2013 at 12:15 AM, Kasper Sørensen <
>> [email protected]> wrote:
>>
>>> Allow me to also bump this issue.
>>>
>>> Since this would be a change that would not be compile-time
>>> incompatible with previous versions, I suggest we introduce at least
>>> the return type of the method now. Since everyone moving the Apache
>>> MetaModel from the old metamodel would anyways have to recompile, they
>>> would not feel the runtime incompatibility of void vs. SomeReturnType.
>>>
>>> By now I suggest we just keep a very simple returned interface which
>>> we can always choose to expand (implemented internally, not by
>>> consumers). For instance something like:
>>>
>>> public interface UpdateStatus {
>>> public int getInsertedRows();
>>> public int getUpdatedRows();
>>> public int getDeletedRows();
>>> }
>>>
>>> This should be quite easy to implement once and reuse for most of the
>>> modules. For some datastores it might not be information that we can
>>> retrieve, so the interface should also specify an extraordinary rule;
>>> e.g. "if -1 is returned it means that it is not known how many rows
>>> where inserted/updated/deleted"
>>>
>>> Kasper
>>>
>>> 2013/7/24 Kasper Sørensen <[email protected]>:
>>>> In the current API design of MetaModel, the
>>> DataContext.executeUpdate(...)
>>>> method is a void method. This was initially chosen because not all
>>>> implementations have the capability to report anything about a particular
>>>> update. But some do, for instance the no. of inserted, updated or deleted
>>>> records from a JDBC call. It would be nice to expose this information
>>> when
>>>> available.
>>>>
>>>> My suggestion for this would be to let the DataContext.executeUpdate(...)
>>>> method return an object with this information. All methods on the new
>>> object
>>>> type would be optionally returning null, if no information is available.
>>> But
>>>> when available, we can at least expose it this way.
>>>>
>>>> The change wouldn't have a major impact, since any project using
>>> MetaModel
>>>> would already need to recompile because of the namespace change to
>>>> org.apache.metamodel. And the change would be compile-time compatible
>>> with
>>>> having a void return type.
>>>
