10:03 p.m.
This property is defined in hibernate-ogm-core and while it's quite
self-explanatory with other NoSQL stores, it doesn't translate nicely
to the Infinispan scenario.
I'd be tempted to introduce ad-hoc properties for each Dialect so that
their effect is clear, allowing to pick more fitting names.
We also like to keep configuration properties to the minimun. In fact
I'd like to simply use Environment.HBM2DDL_AUTO to create / define
Caches ?
Conceptually in Infinispan they are closer to "tables" than
"databases", except they are all schema less and we deploy a schema
using a different operation..
Let the fight begin!
Thanks,
Sanne
11:23 a.m.
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.
Davide
On Wed, Sep 27, 2017 at 9:55 AM, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero
<sanne(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:26 a.m.
On 27 September 2017 at 10:23, Davide D'Alto <davide(a)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(a)gmail.com> wrote:
> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero <sanne(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:12 p.m.
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.
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?
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).
On Wed, Sep 27, 2017 at 10:26 AM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> On 27 September 2017 at 10:23, Davide D'Alto <davide(a)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(a)gmail.com> wrote:
>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero
<sanne(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:14 p.m.
On 27 September 2017 at 11:12, Davide D'Alto <davide(a)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(a)hibernate.org> wrote:
> On 27 September 2017 at 10:23, Davide D'Alto <davide(a)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(a)gmail.com> wrote:
>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero
<sanne(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:08 p.m.
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).
--Gunnar
2017-09-27 13:14 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
On 27 September 2017 at 11:12, Davide D'Alto
<davide(a)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(a)hibernate.org>
wrote:
>> On 27 September 2017 at 10:23, Davide D'Alto <davide(a)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(a)gmail.com> wrote:
>>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero <
sanne(a)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(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
2:19 p.m.
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(a)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?
Thanks,
Sanne
--Gunnar
2017-09-27 13:14 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> On 27 September 2017 at 11:12, Davide D'Alto <davide(a)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(a)hibernate.org>
> > wrote:
> >> On 27 September 2017 at 10:23, Davide D'Alto
<davide(a)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(a)gmail.com> wrote:
> >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero
> >>>> <sanne(a)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(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
2:29 p.m.
2017-09-27 14:19 GMT+02:00 Sanne Grinovero <sanne(a)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(a)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.
Thanks,
Sanne
>
> --Gunnar
>
> 2017-09-27 13:14 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>>
>> On 27 September 2017 at 11:12, Davide D'Alto <davide(a)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(a)hibernate.org>
>> > wrote:
>> >> On 27 September 2017 at 10:23, Davide D'Alto
<davide(a)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(a)gmail.com> wrote:
>> >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero
>> >>>> <sanne(a)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(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
>
>
2:55 p.m.
On 27 September 2017 at 13:29, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2017-09-27 14:19 GMT+02:00 Sanne Grinovero <sanne(a)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(a)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(a)hibernate.org>:
> >>
> >> On 27 September 2017 at 11:12, Davide D'Alto
<davide(a)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(a)hibernate.org>
> >> > wrote:
> >> >> On 27 September 2017 at 10:23, Davide D'Alto
<davide(a)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(a)gmail.com> wrote:
> >> >>>> On Tue, Sep 26, 2017 at 10:03 PM, Sanne Grinovero
> >> >>>> <sanne(a)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(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
> >
> >
12:45 p.m.
I'm working on it.
On Tue, Oct 10, 2017 at 11:36 AM, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
On Wed, Sep 27, 2017 at 2:55 PM, Sanne Grinovero
<sanne(a)hibernate.org> wrote:
> But essentially looks we're on the same page about using HBM2DDL_AUTO
> and ignoring "create_database" for the sake of practical usage.
Just to be sure, in the end, did we do it?
--
Guillaume
1:08 p.m.
OK cool, just wanted to be sure we didn't forget about it!
On Tue, Oct 10, 2017 at 12:45 PM, Davide D'Alto <davide(a)hibernate.org> wrote:
I'm working on it.
On Tue, Oct 10, 2017 at 11:36 AM, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
> On Wed, Sep 27, 2017 at 2:55 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>> But essentially looks we're on the same page about using HBM2DDL_AUTO
>> and ignoring "create_database" for the sake of practical usage.
>
> Just to be sure, in the end, did we do it?
>
> --
> Guillaume
2389
days inactive
2403
days old
12 comments
4 participants
participants (4)
-
Davide D'Alto -
Guillaume Smet -
Gunnar Morling -
Sanne Grinovero