Another candidate for a breaking API change: Getting rid of arrays in the API of MetaModel, and replace them with collections.
Why? I have a couple of reasons that I have run into: 1) Collections are easier to mock in testing scenarios. 2) Collections can be made immutable (or just unmodifiable to consumers) 3) Collections can be lazy evaluated (makes lazy metadata loading a lot easier for us to implement) While these seem like important issues to address, I am myself actually feeling a bit hesitant to make such a change. It would impact just about any use of MetaModel out there maybe the price is too high. In practice these issues have so far been adressed like this: 1) Only mocking of the individual array elements was possible. 2) When necesary, an array copy will be returned instead of the original array. Thus modifications are at least harmless. 3) Lazy loading has been implemented in the sense that these arrays are themselves not loaded before necesary, but the array itself has to be allocated/sized and lazy stubs needs at least to be added eagerly. In practice we've not seen outragously large arrays, so memory-wise it hasn't been a problem. Here's a list of places where arrays are returned, and where a collection type would probably be better suited: DataContext.getSchemas() DataContext.getSchemaNames() Schema.getTables() Schema.getTableNames() Table.getColumns() Table.getColumnNames() Table.getPrimaryKeys() Table.getForeignKeys() Table.getIndexedColumns() Table.getLiteralColumns() Table.getBooleanColumns() Table.getNumberColumns() Table.getTimeBasedColumns() Table.getColumnsOfType(...) Table.getColumnsOfSuperType(...) Table.getRelationships() FilterItem.getChildItems() FilterItem.getOrItems() FromItem.getLeftOn() FromItem.getRightOn()
