[
https://issues.apache.org/jira/browse/SIS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-416:
------------------------------------
Description:
The {{org.apache.sis.storage}} package contains a {{Resource}} interface which
is the root of all resources loaded by a data store ({{FeatureSet}},
{{Aggregate}}, _etc._). The resources do not tell us which data store created
them. In some case we need this information, for example in order to fetch the
parameters used for opening the data store.
We could add {{getOriginatingStore()}} method in {{Resource}} interface, but
not all resources are produced by a data store (a resource could be computed by
a model for example). We could use an {{Optional<DataStore>}} return type, but
{{Optional}} is not convenient with objects making extensive use of checked
exceptions, because lambda functions are difficult to use in that context.
A an alternative would be to define the {{getOriginatingStore()}} method in a
{{StoreResource}} sub-interface, to be implemented only by resources produced
by data stores. It would be the only method of that interface.
Inconvenient of {{StoreResource}} sub-interface:
* it is very easy to forget to implement it.
* It is more difficult to implement by wrappers (need to prepare many
sub-classes for different combination of implemented interfaces).
* Adding a type expands the API in a more intrusive way than adding a method.
Inconvenient of method with {{Optional<DataStore>}} return type:
* Most {{Optional}} methods are unusable because of checked exceptions.
* This method make little sense in {{DataStore}} (which is itself a
{{Resource}}).
was:
The {{org.apache.sis.storage}} package contains a {{Resource}} interface which
is the root of all resources loaded by a data store ({{FeatureSet}},
{{Aggregate}}, _etc._). The resources do not tell us which data store created
them. In some case we need this information, for example in order to be fetch
the parameters used for opening the data store.
We could add {{getDataStore()}} method in {{Resource}}, but not all resources
are produced by a data store (a resource could be computed by a model for
instance). A possible approach would be to define this method in a
{{StoreResource}} sub-interface, to be implemented only by resources produces
by data stores.
Some open questions are:
* What should be the behavior if a resource is used after the data store has
been closed;
* Do we really want those resources to keep a reference to their data store?
> Consider adding StoreResource interface
> ---------------------------------------
>
> Key: SIS-416
> URL: https://issues.apache.org/jira/browse/SIS-416
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Storage
> Affects Versions: 0.8, 1.0, 1.1, 1.2
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Major
> Fix For: 1.3
>
>
> The {{org.apache.sis.storage}} package contains a {{Resource}} interface
> which is the root of all resources loaded by a data store ({{FeatureSet}},
> {{Aggregate}}, _etc._). The resources do not tell us which data store created
> them. In some case we need this information, for example in order to fetch
> the parameters used for opening the data store.
> We could add {{getOriginatingStore()}} method in {{Resource}} interface, but
> not all resources are produced by a data store (a resource could be computed
> by a model for example). We could use an {{Optional<DataStore>}} return type,
> but {{Optional}} is not convenient with objects making extensive use of
> checked exceptions, because lambda functions are difficult to use in that
> context.
> A an alternative would be to define the {{getOriginatingStore()}} method in a
> {{StoreResource}} sub-interface, to be implemented only by resources produced
> by data stores. It would be the only method of that interface.
> Inconvenient of {{StoreResource}} sub-interface:
> * it is very easy to forget to implement it.
> * It is more difficult to implement by wrappers (need to prepare many
> sub-classes for different combination of implemented interfaces).
> * Adding a type expands the API in a more intrusive way than adding a method.
> Inconvenient of method with {{Optional<DataStore>}} return type:
> * Most {{Optional}} methods are unusable because of checked exceptions.
> * This method make little sense in {{DataStore}} (which is itself a
> {{Resource}}).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
