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 Wed, 21 Aug 2013 12:47:55 GMT
Hi Rohit,

It's been a little while now and I just wanted to check if you're
still on this task? IMO we gotta make some progress soon if we want to
include it in a release. Let it be heard if you're facing issues.


2013/8/12 Kasper Sørensen <>:
> Absolutely, that would be a wonderful start! :-)
> 2013/8/12 Rohit <>:
>> Agreed.
>> In order to start contributing to the Metamodel.
>> As a first step can I provide you a patch of this,
>> then you can guide further ?
>> Thanks,
>> Rohit
>> On 11-Aug-2013, at 3:30 PM, Kasper Sørensen <>
>>> The main development branch is 'master'. The .executeUpdate(...) method is
>>> in the subinterface UpdateableDataContext.
>>> My point is that you can provide an update script with many operations in
>>> one go. Take this example:
>>> UpdateStatus status = dataContext.executeUpdate(new UpdateScript() {
>>>>  public void run(UpdateCallback cb) {
>>>>    cb.insertInto(table).value(...).execute();
>>>>    cb.insertInto(table).value(...).execute();
>>>>    cb.update(table).where(...).value(...).execute();
>>>>    cb.deleteFrom(table).where(...).execute();
>>>>  }
>>>> });
>>> In this example we know that 2 records have been inserted. Some amount of
>>> records have been updated (that may or may not be reported by the backing
>>> datastore) and some amount of records have been deleted (that may or may
>>> not have been reported by the backing datastore).
>>> Getting a list of affected records would be very complicated IMO, and would
>>> only be consistent if done at the time of the transaction. That means that
>>> if we even figure out how to do it, we also have to do it eagerly, which is
>>> obviously not a good thing to do since I think getting that list is a
>>> feature that would not apply to most use cases.
>>> The idea about doing this in a multithreaded/nonblocking fashion is
>>> interesting. It would definately have to be an option in my opinion, since
>>> I think the interface right now indicates that the executeUpdate method
>>> will return succesfully when the update is done (ie. it throws those
>>> exceptions that may arise during the update, and an unblocking variant
>>> would not be able to do that).
>>> 2013/8/11 Rohit <>
>>>> 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 <
>>>>> 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 <>:
>>>>>> 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
>>>> 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
>>>> 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 <
>>>>> wrote:
>>>>>>> My experience with returning something like an
>>>>>>> int/String/other-simple-type is that it seems to fit the purpose
>>>>>>> first, but then someone asks "couldn't we also get the status
>>>>>>> [something], too?" ... and then you regret not encapsulating
>>>>>>> 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
>>>>>>>> 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
>>>> 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
>>>>>>>>> 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
>>>> 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
>>>> 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