metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <>
Subject Re: [DISCUSS] get back update status after invoking executeUpdate(...)
Date Sun, 11 Aug 2013 07:34:07 GMT
I agree on the reasoning here, but getting a list of affected rows may
prove to be both quite difficult (from consistency point of view it
needs to be created immediately after some update - how can that be
implemented in an effecient manner (lazy, since you wouldn't always
want to get this list, but then consistency is gone), and how to
guarantee that those rows are even available (e.g. after a DELETE
statement in a JDBC database, you cannot get the rows anymore)), and
too memory intensive (updates can be anything from a single record to
millions of records).

That's why I think the three methods (maybe with an additional fourth
method, returning the total num. of affected rows) is the best initial
set of methods.

2013/8/11 Rohit <>:
> 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 <>
>> 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 <>:
>>> 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 <
>>>> 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 <>:
>>>>> 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.

View raw message