My point is why do we need 3 methods to provide the status ? We can use one
method to provide the status (Returns a boolean if update operation a done or
not) and other to provide a list of affected rows/objects keys, this would be
less memory intensive.
And in case of deletion we can throw a custom exception stating " since this is
a delete operation we cannot provide affected rows".
>>>>> public interface UpdateStatus {
>>>>> public <List or Collection> getAffectedRowsKeys(); or use
>>>>> getRowsKeys(); or getKeys() throws MetaModelException;
public Boolean isDone();
>>>>> }
I see following remote branches in git repo:
remotes/origin/HEAD -> origin/master
remotes/origin/hbase-module
remotes/origin/master
Which is the current development branch as I couldn't find executeUpdate in
DataContext ?
On 11-Aug-2013, at 1:04 PM, Kasper Sørensen <[email protected]>
wrote:
> 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 <[email protected]>:
>> 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.
>>>>>
>>
