[jira] [Comment Edited] (METAMODEL-7) Use collections instead of arrays in API

["Joerg Unbehauen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/METAMODEL-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103473#comment-16103473 ] 

Joerg Unbehauen edited comment on METAMODEL-7 at 7/27/17 4:47 PM:
------------------------------------------------------------------

It is a lot of work.

But i started it anyway:  https://github.com/tomatophantastico/metamodel/tree/feature/collectionsInterfaces

This is work in progress!



was (Author: tomatophantastico):
It is a lot of work.

But i started it anyway:  https://github.com/tomatophantastico/metamodel/tree/feature/collectionsInterfaces



> Use collections instead of arrays in API
> ----------------------------------------
>
>                 Key: METAMODEL-7
>                 URL: https://issues.apache.org/jira/browse/METAMODEL-7
>             Project: Apache MetaModel
>          Issue Type: Wish
>            Reporter: Kasper Sørensen
>            Assignee: Kasper Sørensen
>            Priority: Trivial
>             Fix For: 5.0.0
>
>
> 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()



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)