6:08 p.m.
Hi,
Davide brought up an interesting issue while reviewing a PR around the OGM
backend for CouchDB [1].
This PR makes use of the new Option API and allows to configure
CouchDB-specific settings in a safe way. For that purpose each dialect
needs to provide a sub-class of DatastoreConfiguration which is then passed
to configureDatastore() like this:
OgmSessionFactory factory = ...;
factory.configureDatastore( CouchDB.class )
.associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
Now I had defined a constant on CouchDB for the property name for setting
the association storage type via OgmConfiguration, not being fully aware of
the existing interface Environment which defines some other constants such
as host name property etc.
Our question is, should now that we have the Option API and with it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?
I think that'd make sense, also having in mind that we might expose
settings configured via OgmConfiguration via an equivalent global option at
some point. Also having distinct class names will be beneficial in polyglot
persistence scenarios where one needs to configure several stores.
What do others think?
--Gunnar
[1] https://github.com/hibernate/hibernate-ogm/pull/261
6:36 p.m.
Our question is, should now that we have the Option API and with it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?
Yes, +1
On Wed, Dec 11, 2013 at 5:08 PM, Gunnar Morling <gunnar(a)hibernate.org>wrote:
> Hi,
>
> Davide brought up an interesting issue while reviewing a PR around the OGM
> backend for CouchDB [1].
>
> This PR makes use of the new Option API and allows to configure
> CouchDB-specific settings in a safe way. For that purpose each dialect
> needs to provide a sub-class of DatastoreConfiguration which is then passed
> to configureDatastore() like this:
>
> OgmSessionFactory factory = ...;
> factory.configureDatastore( CouchDB.class )
> .associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
>
> Now I had defined a constant on CouchDB for the property name for setting
> the association storage type via OgmConfiguration, not being fully aware of
> the existing interface Environment which defines some other constants such
> as host name property etc.
>
Our question is, should now that we have the Option API and with it
> store-specific DatastoreConfiguration types, the previously used
> Environment interfaces be removed and their constants moved to the
> corresponding DatastoreConfiguration type?
>
> I think that'd make sense, also having in mind that we might expose
> settings configured via OgmConfiguration via an equivalent global option at
> some point. Also having distinct class names will be beneficial in polyglot
> persistence scenarios where one needs to configure several stores.
>
> What do others think?
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-ogm/pull/261
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
9:07 a.m.
I did not see that thread when I opened the constant naming unification.
I am a bit skeptical that option should be used for global settings like host and co but
let's try and see where that leads us.
On 11 déc. 2013, at 18:36, "Davide D'Alto" <daltodavide(a)gmail.com>
wrote:
> Our question is, should now that we have the Option API and with
it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?
Yes, +1
On Wed, Dec 11, 2013 at 5:08 PM, Gunnar Morling <gunnar(a)hibernate.org>wrote:
> Hi,
>
> Davide brought up an interesting issue while reviewing a PR around the OGM
> backend for CouchDB [1].
>
> This PR makes use of the new Option API and allows to configure
> CouchDB-specific settings in a safe way. For that purpose each dialect
> needs to provide a sub-class of DatastoreConfiguration which is then passed
> to configureDatastore() like this:
>
> OgmSessionFactory factory = ...;
> factory.configureDatastore( CouchDB.class )
> .associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
>
> Now I had defined a constant on CouchDB for the property name for setting
> the association storage type via OgmConfiguration, not being fully aware of
> the existing interface Environment which defines some other constants such
> as host name property etc.
>
> Our question is, should now that we have the Option API and with it
> store-specific DatastoreConfiguration types, the previously used
> Environment interfaces be removed and their constants moved to the
> corresponding DatastoreConfiguration type?
>
> I think that'd make sense, also having in mind that we might expose
> settings configured via OgmConfiguration via an equivalent global option at
> some point. Also having distinct class names will be beneficial in polyglot
> persistence scenarios where one needs to configure several stores.
>
> What do others think?
>
> --Gunnar
>
> [1] https://github.com/hibernate/hibernate-ogm/pull/261
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3787
days inactive
3789
days old
2 comments
3 participants
participants (3)
-
Davide D'Alto -
Emmanuel Bernard -
Gunnar Morling