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. >>
