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

Wed Sep 27 08:55:53 EDT 2017

On 27 September 2017 at 13:29, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
> 2017-09-27 14:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Thanks Gunnar, at an high level that's pretty much on the same page
>> than everyone else, but some details are relevant:
>>
>> On 27 September 2017 at 13:08, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> > I'd suggest to
>> >
>> > * simply ignore "create database" for Infinispan (not all OGM-defined
>> > properties are supported for all stores)
>> > * implement support for HBM2DDL_AUTO to create tables (or caches etc.)
>> > *within* the chosen database (which will be ISPN's global namespace as
>> > there
>> > is no notion of databases there)
>> >
>> > I would not make database creation part of the HBM2DDL_AUTO
>> > implementation,
>> > since that's not the case on ORM either (AFAIK, one would specify some
>> > parameter to the connection URL for having the database created if
>> > needed).
>>
>> I'm confused. You say we should create the "tables" but we should NOT
>> create the "database" when this property is enabled.
>>
>> My previous email just explained that Infinispan has neither tables
>> nor databases; we conceptually conflate both concepts into "Cache",
>> were making a distinction is a grey area.
>> So what are you suggesting we do?
>
>
> In my picture of our usage, caches are ISPN's counterpart to tables in an
> RDBMS. Hence the proposal to control cache creation via HBM2DDL, akin to
> ORM's semantics of that option. AFAIU, thinking about database creation
> doesn't make sense for ISPN, as this concept just doesn't exist (or, one can
> think of it as exactly one "database" which always exists).
>
> Btw.
>
>> ... different approaches in embedded mode: storing all entities in the
>> same Infinispan Cache
>
> That sounds kinda weird, isn't it like storing all entities in a single
> table in an RDMBS? It seems rather (space)-inefficient, as you always need
> to store the entity type as part of the key. With some distance, using one
> cache per entity (ignoring inheritance for a moment) seems like the most
> sensible mapping to me.

Yes this might sound weird if you look at them as tables, but that's
just one way of looking at it.

We can both agree that this is "sensible" but beyond our small team
this is not knowledge that people will have when they start using OGM
so I wouldn't assume the table-Cache match, especially not to explain
further concepts.

Also remember that in this case we're talking about "creating the
table" as a "storage space". The schema and definitions of the table
content types are actually managed separately in Infinispan..
I didn't want to bring this up as the thread is complex enough but it
might help us to realize that we can't just consider all these
concepts as one and swipe the differences under the carpet,
as the user will need to understand some critical points, e.g. how to
evolve the schema over time.

But essentially looks we're on the same page about using HBM2DDL_AUTO
and ignoring "create_database" for the sake of practical usage.

Thanks for the brainstorming!
Sanne

>
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> >
>> > --Gunnar
>> >
>> > 2017-09-27 13:14 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> 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
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>