I actually think it's much simpler problem than being JDBC-like or not; Someone asks to retrieve a set of values from some kind of datastore (SQL or otherwise). When done, they suddenly try to retrieve another set of values. That's most probably a bug in their code, and in my mind we should explode immediately.
I wouldn't compare it to a Map. A Map just returns null, because it is a general purpose structure that can't start limiting uses like that. We can, and IMHO we should. (By the way, JIRA is up again. I mostly reply here because my reply would seem weird on its own :)) BR, Dennis -----Original Message----- From: Kasper Sørensen [mailto:[email protected]] Sent: 12. maj 2016 19:24 To: [email protected] Subject: Regarding METAMODEL-251 Since JIRA is unavailable, I will reply to the discussion of METAMODEL-251 [1] via mail... I agree that the change would make MetaModel more "JDBC like". But I don't see JDBC as a very good rolemodel for MetaModel, rather I just feel that MetaModel lends on SQL as a query structure rather than JDBC itself. At least I don't think that there's an intrinsic value in being "JDBC like" for us since it seems most people anyway prefer higher level APIs such as JPA, LINQ or ... MetaModel :-) Maybe we can start by adding the containsColumn(Column) and containsSelectItem(SelectItem) methods to the Row interface? That should be doable without breaking too many things. Then you could consider adding a StrictRow class as a wrapper around it. Even just for debugging your issue? An alternative would also be to have some kind of system property which we could set to influence what type of behaviour we want - to determine if we would return null or throw an exception. [1] https://issues.apache.org/jira/browse/METAMODEL-251
