metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <i.am.kasper.soren...@gmail.com>
Subject Re: [DISCUSS] get back update status after invoking executeUpdate(...)
Date Sun, 11 Aug 2013 10:00:28 GMT
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 <rohit0286@gmail.com>

>
> 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 <
> i.am.kasper.sorensen@gmail.com> 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 <rohit0286@gmail.com>:
> >> 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 <
> i.am.kasper.sorensen@gmail.com> 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 <henry.saputra@gmail.com>:
> >>>> 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 <
> >>>> i.am.kasper.sorensen@gmail.com> 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 <i.am.kasper.sorensen@gmail.com>:
> >>>>>> 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.
> >>>>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message