[
https://issues.apache.org/jira/browse/SIS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17550506#comment-17550506
]
Martin Desruisseaux commented on SIS-416:
-----------------------------------------
We tried to add the following method in the {{Resource}} interface, but this
attempt has been cancelled:
{code:java}
/**
* Returns the data store that produced this resource.
* This information allows for example to fetch the parameters used for
opening the data store.
* A resource may have no originating data store if it was generated, for
example as the result
* of a computation from other data stores.
*
* <p>If this resource is already a {@link DataStore}, then the value is
{@code this}.</p>
*
* @return the data store that created this resource.
* @throws DataStoreException if an error occurred while fetching the store.
* It may happen for example if the store is lazily opened.
*
* @since 1.3
*/
Optional<DataStore> getOriginatingStore() throws DataStoreException;
{code}
The reason for not adding about method yet is because the contract is still
unclear. Should the result of {{subset(Query)}} keep a link to the original
data store? What should be the result of virtual resource such as A+B?. Instead
we tried to clarify the intended contract in the internal {{StoreResource}}
interface and defer the resolution to a yet later stage.
> 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)
