[
https://issues.apache.org/jira/browse/METAMODEL-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054680#comment-15054680
]
ASF GitHub Bot commented on METAMODEL-6:
----------------------------------------
Github user kaspersorensen commented on the pull request:
https://github.com/apache/metamodel/pull/77#issuecomment-164198957
I don't like the idea of suddenly changing our requirement from Java 7 to
Java 8, just because a new feature could benefit from it. I know I'm being a
party-pooper, but I think that kind of stuff needs to be planned and handled in
a way where we give people more choice about when they take the step to Java 8.
If nothing else, the application I (we ;-)) work on most has roughly 40% users
that still are on Java 7, so we wanted to not retire it just yet... But soon
for sure. But other companies are surely more conservative and will wait
longer. My final word on Java 8 would be: Probably there are _many_ more API
improvements we could make if we decide to go with Java 8. I would suggest we
start a separate topic about that and consider that a part of a future
MetaModel 5.0 with renewed API in many places.
> Get back update status after invoking executeUpdate(...)
> --------------------------------------------------------
>
> Key: METAMODEL-6
> URL: https://issues.apache.org/jira/browse/METAMODEL-6
> Project: Apache MetaModel
> Issue Type: Wish
> Reporter: Kasper Sørensen
> Assignee: Kasper Sørensen
> Priority: Minor
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
