Mailing-List: contact dev-help@metamodel.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@metamodel.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 i.am.kasper.sorensen@gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALuGr6aYOpiPwKKH9WEj1HM9pjduO2Va4yHMXpENAhUJe4Rs9w@mail.gmail.com>
References: 
 <CA+U3tt-tNr1zHV+AdRB06SZCCfxvcDqUquEUOsqvadfOxR8T2g@mail.gmail.com>
	<CA+U3tt_2qBXnzes-q60UPqhq1S_FvibczpKaApZKFmh_jaS8+w@mail.gmail.com>
	<CALuGr6aYOpiPwKKH9WEj1HM9pjduO2Va4yHMXpENAhUJe4Rs9w@mail.gmail.com>
Date: Sat, 10 Aug 2013 18:39:36 +0200
Message-ID: 
 <CA+U3tt9RLGgm0zaiVRap9hMiG1EMDZu=Lpvn7TZWRUnwPCH7CQ@mail.gmail.com>
Subject: Re: [DISCUSS] get back update status after invoking
 executeUpdate(...)
From: =?ISO-8859-1?Q?Kasper_S=F8rensen?= <i.am.kasper.sorensen@gmail.com>
To: dev@metamodel.incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=F8rensen <
> 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=F8rensen <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 particu=
lar
>> > update. But some do, for instance the no. of inserted, updated or dele=
ted
>> > 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 availabl=
e.
>> 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.
>>