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" <daltodav...@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 <gun...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
