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.
