[hibernate-dev] Property "ogm.datastore.create_database": fit for purpose?

Sanne Grinovero sanne at hibernate.org
Wed Sep 27 07:14:50 EDT 2017


On 27 September 2017 at 11:12, Davide D'Alto <davide at hibernate.org> wrote:
>> Thanks, but before you jump onto specifics of feasability, do we agree
>> that "create_database" as a name is not good for Infinispan ?
>
> Well, we are using infinispan as a database, it's not an ideal name
> but it is not so terrible considering
> that we are trying to use a single property for all the dialects.

You just served me with a great example. You write "using infinispan
as a database" but then the property name is "create database" then
obviously I'm not suggesting that users are fools and think we're
going to "create an Infinispan" but you can see where this is heading:
it's unclear what it is really creating and the terminology is too
overloaded.

"create database" is good for storage systems like MySQL as there's a
SQL command which literally says "CREATE DATABASE {name};" to express
a group of related tables.

Apparently it works fine with MongoDB too, as "collections" are
grouped in databases.

Infinispan doesn't have the notion of related tables; we as OGM team
are experimenting with different approaches in embedded mode: storing
all entities in the same Infinispan Cache, among 3 specially
configured Infinispan Caches (entities, relation tables, IDs) or have
a "cache per table" strategy. Either way, there might be more Caches
on the system and there's no isolation, so essentially it's a
crossing-fingers strategy that we're not going to overwrite or
otherwise mess with the content of other Infinispan Caches.

The main point being that there's no "database" in the typical logical
sense so - as a user - I'm confused on what this property will do in
the Infinispan Hot Rod context.

> I guess I didn't understand what you are proposing, the issue I linked is about:
>
> 1. Use HBM2DDL_AUTO for database and "table" creation
> 2. Remove create_database
>
> Isn't that what you asked initially?

Yes I'm proposing both 1. and 2.
Just pointing out that I got no answer from you about "2." and I
wouldn't want to do 1. if there's no agreement on both points.

> I'm inclined to have a distinct property for each dialect,  the only
> thing that I don't like about it
> is that we will have several properties doing the same thing
> (basically, create what's missing).

Right, that's my same doubt.
My proposal would be to have both good names which clearly express
what we're going to do in each Dialect, and also apply the DDL_AUTO
option so that Quickstarts, demos and newcomers can get up and running
without needing to know them all. This is why I proposed both points
1. and 2. in the same thread, as we want to make the properties
clearer but ideally we don't want the require the users to know about
all these properties for the most common use cases.

Thanks!

Sanne


>
> On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> On 27 September 2017 at 10:23, Davide D'Alto <davide at hibernate.org> wrote:
>>>> Let the fight begin!
>>>
>>> I don't think we have to fight about it:
>>> https://hibernate.atlassian.net/browse/OGM-571
>>>
>>> It wasn't possible to use Environment.HBM2DDL_AUTO when we introduced
>>> the property,
>>> it should be possible now.
>>>
>>> I'll have a look at it. It seems gunnar had a branch with something
>>> already done.
>>
>> Thanks, but before you jump onto specifics of feasability, do we agree
>> that "create_database" as a name is not good for Infinispan ?
>>
>> Sanne
>>
>>>
>>> Davide
>>>
>>> On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet
>>> <guillaume.smet at gmail.com> wrote:
>>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero <sanne at hibernate.org>
>>>> wrote:
>>>>
>>>>> In fact
>>>>> I'd like to simply use Environment.HBM2DDL_AUTO to create / define
>>>>> Caches ?
>>>>>
>>>>
>>>> Makes sense to me.
>>>>
>>>> --
>>>> Guillaume
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


More information about the hibernate-dev mailing list