Re: [hibernate-dev] Contributing to OGM / Cassandra
Hi Emmanuel & Gunnar, Many thanks for your detailed responses - and nice to chat with Gunnar a week or so back. Again I have to apologise for radio silence - my day job suddenly ate all my waking functional time - so progress has been very slow. I'm getting deeper into the code now, and starting a POC... which is leading me to some more detailed questions. Basically, what I am doing is to run the examples and to look at things that seem to be missing, and toi understand the data that is being passed around in the various options classes, so I can make a more informed implementation The key question in my mind at the moment is that of the relationship between the base Hibernate Dialect class and the GridDialect interface - I look at the OgmTableGenerator which is attempting to access a CF / table that is not yet created - I figured I understand what was happening here, and make appropriate extensions / fixes first. So, currently fighting my way through generating the sequence tables, and wondering why OgmSequnceGenerator wraps OgmtableGenerator. Cheers, John On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard wrote: > On Thu 2014-08-07 9:10, John Worrell wrote: > > Hi Emmanuel et al., > > > > My apologies for the log radio silence. I've taken a look at the > code-base > > on Jon Halliday's repo, and have set up a nick on freenode - #jlesinge. > > No worries I was on holidays. > And you email was the few lucky ones that I had to delay as it required > thinking ;) > > > > > On the time-series question I was wondering how you envisaged the data > > stored: I tend to think of a single row under an primary key with an > > object-instance per column. Now what we have typically done (generally > the > > data has been immutable) is to store the data serialized as a blob (JSON > or > > XML), but I understand you do not favour this approach. With this sort of > > model I imagine the collection is then all the objects stored in the row, > > and the challenge is to page through the objects in the row. > > Actually it is one of the valid strategies. > If I understand you well, you want to create: > > - one row per time series generating object (say a thermometer) > - the column names of that row would be a timestamp of time at bay > - the value would be a JSON structure containing the data at bay for > that specific time. > > That is one of the valid approach. But I think we need to support > several: > > - simple column if the data is literally a single element (temperature) > - JSON structure for more complex data per time event > - key pointing to the detailed data somewhere else in the cluster > > The latest would be done in two phases, you load all the keys you are > interested in matching your time range and then do a multiget of sort to > load the data. > > It seems datastax tends to recommend 1 or 2 (denormalization FTW). > > I don't know but there is also the notion of super column which is a > grouping of columns that might also address our composite problem > assuming they can be used for dynamic column families. > > http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra > > http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling/ > http://www.datastax.com/docs/1.0/ddl/column_family > > > > > An approach we have often taken is to create multiple copies of data in > > different (obviously works well only for immutable objects) or better to > > Yes, that is a feature that I would like OGM to automate for the user. > It declaratively defines the denormalization approaches he wants and the > engine does the persistence. > Next the query engine uses that knowledge to find the best path (or only > possible path in the case of Cassandra :) ) > > > create a table of keys to a main table where in either approach the > > row-keys are effectively a foreign-key and there is column per object > > associated through the foreign-key. Another approach though might be to > use > > a column with type list (or set, or map) to contain keys to the > associated > > objects - this would be a little like the extensions Oracle have for > > mapping 1-* associations, though with the caveat that a column of > > collection type may only contain 64k elements. I wondered if some though > > had been given to this strategy (which I must admit I have not yet used > > myself). > > I am not aware of that approach. > > > > > It seems very likely that different mapping strategies should be > > specifiable, but then I have still to understand how these might fit with > > treiid. > > Forget Teiid for now. We will likely start with the HQL->Walker and do > our own proto query engine before layering Teiid. > > > > > Can I ask about assumptions: is it fair to assume that for Cassandra, OGM > > will target only CQL 3 (which means Cassandra 2 or maybe 1.2)? This would > > certainly make life simpler. > > Yes that's fine. > > > > > An issue I don't see addressed is the choice of consistency-level (read
Re: [hibernate-dev] Contributing to OGM / Cassandra
Hi John, 2014-09-09 10:33 GMT+02:00 John Worrell : > Hi Emmanuel & Gunnar, > > Many thanks for your detailed responses - and nice to chat with Gunnar a > week or so back. Again I have to apologise for radio silence - my day job > suddenly ate all my waking functional time - so progress has been very > slow. > No worries, we are very glad about your help. I'm getting deeper into the code now, and starting a POC... which is > leading me to some more detailed questions. Basically, what I am doing is > to run the examples and to look at things that seem to be missing, and toi > understand the data that is being passed around in the various options > classes, so I can make a more informed implementation > Sounds very reasonable. I also can recommend to take a look at the MongoDB dialect and the persistent representations it creates in the datastore as it can comfortably be browsed e.g. using the mongo command line client. That's how I got to understand many things of the interaction between engine and dialects. If you have any ideas where the dialect SPI documentation can be improved to facilitate an easier understanding of how pieces work together, let me know. The key question in my mind at the moment is that of the relationship > between the base Hibernate Dialect class and the GridDialect interface OGM has its own pseudo implementation of ORM's Dialect contract, OgmDialect, but this should hardly ever play a role during OGM development. OGM's main contract towards dialects is GridDialect. The reason for exposing GridDialect on the pseudo OgmDialect is that it is our backdoor to make GridDialect available to PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to inject the GridDialect in a more straight-forward way due to some limitations in the way we integrate with the ORM engine. > - I > look at the OgmTableGenerator which is attempting to access a CF / table > that is not yet created - I figured I understand what was happening here, > and make appropriate extensions / fixes first. So, currently fighting my > way through generating the sequence tables, and wondering why > OgmSequnceGenerator wraps OgmtableGenerator. > Just to be sure, are you looking at the latest master? There have been some changes around these generator classes recently, they are in a much cleaner state than they used to be. The reason for the wrapping is that when using the SEQUENCE strategy in cases where the store actually does not natively support sequences, we fall back to TABLE. Currently we only support a "native" SEQUENCE strategy for Neo4j which allows to map sequences as nodes in a reasonable manner, whereas all the other dialects use the table fallback. GridDialect#supportsSequences() is evaluated to find out whether the delegation needs to be done or not. You also could take a look at Neo4jSequenceGenerator which creates the sequence nodes in the datastore based on the registered PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose these types on the dialect SPI, I'm looking into ways for allowing the distinction of the two in a more abstract way, mainly based on IdSourceKeyMetadata. Hope that helps, I'll be very happy to answer any follow-up questions. Thanks again for your help with the Cassandra dialect, I'm looking forward to this dialect very much! > > Cheers, > > John > --Gunnar > > > On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard > wrote: > > > On Thu 2014-08-07 9:10, John Worrell wrote: > > > Hi Emmanuel et al., > > > > > > My apologies for the log radio silence. I've taken a look at the > > code-base > > > on Jon Halliday's repo, and have set up a nick on freenode - #jlesinge. > > > > No worries I was on holidays. > > And you email was the few lucky ones that I had to delay as it required > > thinking ;) > > > > > > > > On the time-series question I was wondering how you envisaged the data > > > stored: I tend to think of a single row under an primary key with an > > > object-instance per column. Now what we have typically done (generally > > the > > > data has been immutable) is to store the data serialized as a blob > (JSON > > or > > > XML), but I understand you do not favour this approach. With this sort > of > > > model I imagine the collection is then all the objects stored in the > row, > > > and the challenge is to page through the objects in the row. > > > > Actually it is one of the valid strategies. > > If I understand you well, you want to create: > > > > - one row per time series generating object (say a thermometer) > > - the column names of that row would be a timestamp of time at bay > > - the value would be a JSON structure containing the data at bay for > > that specific time. > > > > That is one of the valid approach. But I think we need to support > > several: > > > > - simple column if the data is literally a single element (temperature) > > - JSON str
Re: [hibernate-dev] Contributing to OGM / Cassandra
Hi Gunnar, Many thanks for the reply - I'll yank down the master... assume it is merged back to the Jon Halliday fork otherwise I'll need to mess about a bit. Also had some issues with getting connected to C*, understandable, but also wrt adding tags for the Dog / Breed classes in the persistence.xml file. not sure whether that is intended to be needed. Cheers, John On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling wrote: > Hi John, > > 2014-09-09 10:33 GMT+02:00 John Worrell : > >> Hi Emmanuel & Gunnar, >> >> Many thanks for your detailed responses - and nice to chat with Gunnar a >> week or so back. Again I have to apologise for radio silence - my day job >> suddenly ate all my waking functional time - so progress has been very >> slow. >> > > No worries, we are very glad about your help. > > I'm getting deeper into the code now, and starting a POC... which is >> leading me to some more detailed questions. Basically, what I am doing is >> to run the examples and to look at things that seem to be missing, and toi >> understand the data that is being passed around in the various options >> classes, so I can make a more informed implementation >> > > Sounds very reasonable. I also can recommend to take a look at the MongoDB > dialect and the persistent representations it creates in the datastore as > it can comfortably be browsed e.g. using the mongo command line client. > That's how I got to understand many things of the interaction between > engine and dialects. > > If you have any ideas where the dialect SPI documentation can be improved > to facilitate an easier understanding of how pieces work together, let me > know. > > The key question in my mind at the moment is that of the relationship >> between the base Hibernate Dialect class and the GridDialect interface > > > OGM has its own pseudo implementation of ORM's Dialect contract, > OgmDialect, but this should hardly ever play a role during OGM development. > OGM's main contract towards dialects is GridDialect. > > The reason for exposing GridDialect on the pseudo OgmDialect is that it is > our backdoor to make GridDialect available to > PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to > inject the GridDialect in a more straight-forward way due to some > limitations in the way we integrate with the ORM engine. > > >> - I >> look at the OgmTableGenerator which is attempting to access a CF / table >> that is not yet created - I figured I understand what was happening here, >> and make appropriate extensions / fixes first. So, currently fighting my >> way through generating the sequence tables, and wondering why >> OgmSequnceGenerator wraps OgmtableGenerator. >> > > Just to be sure, are you looking at the latest master? There have been > some changes around these generator classes recently, they are in a much > cleaner state than they used to be. > > The reason for the wrapping is that when using the SEQUENCE strategy in > cases where the store actually does not natively support sequences, we fall > back to TABLE. Currently we only support a "native" SEQUENCE strategy for > Neo4j which allows to map sequences as nodes in a reasonable manner, > whereas all the other dialects use the table fallback. > GridDialect#supportsSequences() is evaluated to find out whether the > delegation needs to be done or not. > > You also could take a look at Neo4jSequenceGenerator which creates the > sequence nodes in the datastore based on the registered > PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof > for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose > these types on the dialect SPI, I'm looking into ways for allowing the > distinction of the two in a more abstract way, mainly based on > IdSourceKeyMetadata. > > Hope that helps, I'll be very happy to answer any follow-up questions. > Thanks again for your help with the Cassandra dialect, I'm looking forward > to this dialect very much! > > >> >> Cheers, >> >> John >> > > --Gunnar > > >> >> >> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard > > >> wrote: >> >> > On Thu 2014-08-07 9:10, John Worrell wrote: >> > > Hi Emmanuel et al., >> > > >> > > My apologies for the log radio silence. I've taken a look at the >> > code-base >> > > on Jon Halliday's repo, and have set up a nick on freenode - >> #jlesinge. >> > >> > No worries I was on holidays. >> > And you email was the few lucky ones that I had to delay as it required >> > thinking ;) >> > >> > > >> > > On the time-series question I was wondering how you envisaged the data >> > > stored: I tend to think of a single row under an primary key with an >> > > object-instance per column. Now what we have typically done (generally >> > the >> > > data has been immutable) is to store the data serialized as a blob >> (JSON >> > or >> > > XML), but I understand you do not favour this approach. With this >> sort of >> > > model I imagine the collection is then all the objects stored in the >> ro
Re: [hibernate-dev] Contributing to OGM / Cassandra
Hi, 2014-09-09 11:08 GMT+02:00 John Worrell : > Hi Gunnar, > > Many thanks for the reply - I'll yank down the master... assume it is > merged back to the Jon Halliday fork otherwise I'll need to mess about a > bit. > Not sure when Jon's branch was updated for the last time. Probably you need to rebase (we prefer to work with rebases rather than merge commits) your local branch onto the latest master from upstream. There have been some changes around GridDialect in the last time, mainly about query execution and id generation. Nothing dramatic, though. > Also had some issues with getting connected to C*, understandable, but > also wrt adding tags for the Dog / Breed classes in the > persistence.xml file. not sure whether that is intended to be needed. > You mean the classes from the "Getting Started" example, right? The tags should not be required, the example runs as is e.g. on Infinispan. What happens if you don't add those? Cheers, > > John > --Gunnar On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling wrote: > >> Hi John, >> >> 2014-09-09 10:33 GMT+02:00 John Worrell : >> >>> Hi Emmanuel & Gunnar, >>> >>> Many thanks for your detailed responses - and nice to chat with Gunnar a >>> week or so back. Again I have to apologise for radio silence - my day job >>> suddenly ate all my waking functional time - so progress has been very >>> slow. >>> >> >> No worries, we are very glad about your help. >> >> I'm getting deeper into the code now, and starting a POC... which is >>> leading me to some more detailed questions. Basically, what I am doing is >>> to run the examples and to look at things that seem to be missing, and >>> toi >>> understand the data that is being passed around in the various options >>> classes, so I can make a more informed implementation >>> >> >> Sounds very reasonable. I also can recommend to take a look at the >> MongoDB dialect and the persistent representations it creates in the >> datastore as it can comfortably be browsed e.g. using the mongo command >> line client. That's how I got to understand many things of the interaction >> between engine and dialects. >> >> If you have any ideas where the dialect SPI documentation can be improved >> to facilitate an easier understanding of how pieces work together, let me >> know. >> >> The key question in my mind at the moment is that of the relationship >>> between the base Hibernate Dialect class and the GridDialect interface >> >> >> OGM has its own pseudo implementation of ORM's Dialect contract, >> OgmDialect, but this should hardly ever play a role during OGM development. >> OGM's main contract towards dialects is GridDialect. >> >> The reason for exposing GridDialect on the pseudo OgmDialect is that it >> is our backdoor to make GridDialect available to >> PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to >> inject the GridDialect in a more straight-forward way due to some >> limitations in the way we integrate with the ORM engine. >> >> >>> - I >>> look at the OgmTableGenerator which is attempting to access a CF / table >>> that is not yet created - I figured I understand what was happening here, >>> and make appropriate extensions / fixes first. So, currently fighting my >>> way through generating the sequence tables, and wondering why >>> OgmSequnceGenerator wraps OgmtableGenerator. >>> >> >> Just to be sure, are you looking at the latest master? There have been >> some changes around these generator classes recently, they are in a much >> cleaner state than they used to be. >> >> The reason for the wrapping is that when using the SEQUENCE strategy in >> cases where the store actually does not natively support sequences, we fall >> back to TABLE. Currently we only support a "native" SEQUENCE strategy for >> Neo4j which allows to map sequences as nodes in a reasonable manner, >> whereas all the other dialects use the table fallback. >> GridDialect#supportsSequences() is evaluated to find out whether the >> delegation needs to be done or not. >> >> You also could take a look at Neo4jSequenceGenerator which creates the >> sequence nodes in the datastore based on the registered >> PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof >> for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose >> these types on the dialect SPI, I'm looking into ways for allowing the >> distinction of the two in a more abstract way, mainly based on >> IdSourceKeyMetadata. >> >> Hope that helps, I'll be very happy to answer any follow-up questions. >> Thanks again for your help with the Cassandra dialect, I'm looking forward >> to this dialect very much! >> >> >>> >>> Cheers, >>> >>> John >>> >> >> --Gunnar >> >> >>> >>> >>> On Fri, Aug 22, 2014 at 5:25 PM, Emmanuel Bernard < >>> emman...@hibernate.org> >>> wrote: >>> >>> > On Thu 2014-08-07 9:10, John Worrell wrote: >>> > > Hi Emmanuel et al., >>> > > >>> > > My apologies for the log radio silence. I've taken a look at the >>> > c
Re: [hibernate-dev] Possible bug in hibernate-validator ValidatorImpl
Opened https://hibernate.atlassian.net/browse/HV-928
thanks :)
From: gunnar.morl...@googlemail.com on behalf
of Gunnar Morling
Sent: Thursday, August 21, 2014 2:57 PM
To: Itai Frenkel
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Possible bug in hibernate-validator ValidatorImpl
Hi,
2014-08-21 12:38 GMT+02:00 Itai Frenkel
mailto:i...@forter.com>>:
Hello,
TL;DR: Need an opinion if to open a JIRA (since reproduction is very tricky)
I am using the @UnwrapValidatedValue with a custom Guava OptionalUnwrapper and
sometimes OptionalUnwrapper#getValidatedValueType() is called also for
non-Optional<> fields.
The bug reproduction is sporadic and tricky.
If you say sporadic, does it mean validating one and the same POJO sometimes
shows the issue and in some other cases it doesn't, without altering any parts
of the code?
I managed to pinpoint it to
ValidatorImpl#setValidatedValueHandlerToValueContextIfPresent() that does not
perform valueContext.setValidatedValueHandler( null ) when there is no need for
an unwrapper. Since valueContext is re-used between fields, it is possible for
the OptionalUnwrapper to be first called for Optional fields and then re-used
for non-Optional fields with the same validatedValueHandler of the Optional
field.
Interesting, this doesn't seem correct indeed. Without having a closer look I'd
say the un-wrapper should be reset on the context between validation of
different properties.
If the code owner could quickly comment on this, it would be great.
It sounds like a legitimate bug description, so I suggest you move forward and
open an issue in JIRA (https://hibernate.atlassian.net/browse/HV). It would be
great if you could attach a complete executable test case which demonstrates
the issue.
below are some code snippets I used.
public class SomePOJO {
@DecimalMin(value="0", inclusive=true)
public Integer x = -1;
@UnwrapValidatedValue
@DecimalMin(value="1", inclusive=true)
public Optional y = Optional.of(-1);
@DecimalMin(value="0", inclusive=true)
public Integer z = -1;
}
public class OptionalUnwrapper extends ValidatedValueUnwrapper> {
private final TypeResolver typeResolver;
public OptionalUnwrapper() {
typeResolver = new TypeResolver();
}
@Override
public Object handleValidatedValue(Optional optional) {
return optional == null? null : optional.orNull();
}
@Override
public Type getValidatedValueType(Type valueType) {
final TypeToken typeToken = TypeToken.of(valueType);
if (typeToken.getRawType().isAssignableFrom(Optional.class)) {
Type rawType =
typeToken.resolveType(Optional.class.getTypeParameters()[0]).getType();
return rawType;
}
else {
Type rawType = typeToken.getType();
Preconditions.checkArgument(false, "type " + rawType + " is not
supported by " + this.getClass() );
return null;
}
}
}
Thanks for reporting this issue, much appreciated!
Cheers,
--Gunnar
___
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
Re: [hibernate-dev] Contributing to OGM / Cassandra
Hi Gunnar, Wrt the tags - partly it is an issue with Eclipse JPA which complains if the tags are absent, but I think it *may* actually not make any difference to the examples - the real issue lies with the code not picking up the sequences to generate properly, and as you point out that may now be fixed in the latest master. I'll look at a rebase. Thanks, John On Tue, Sep 9, 2014 at 10:36 AM, Gunnar Morling wrote: > Hi, > > 2014-09-09 11:08 GMT+02:00 John Worrell : > >> Hi Gunnar, >> >> Many thanks for the reply - I'll yank down the master... assume it is >> merged back to the Jon Halliday fork otherwise I'll need to mess about a >> bit. >> > > Not sure when Jon's branch was updated for the last time. > > Probably you need to rebase (we prefer to work with rebases rather than > merge commits) your local branch onto the latest master from upstream. > There have been some changes around GridDialect in the last time, mainly > about query execution and id generation. Nothing dramatic, though. > > >> Also had some issues with getting connected to C*, understandable, but >> also wrt adding tags for the Dog / Breed classes in the >> persistence.xml file. not sure whether that is intended to be needed. >> > > You mean the classes from the "Getting Started" example, right? The > tags should not be required, the example runs as is e.g. on > Infinispan. What happens if you don't add those? > > Cheers, >> >> John >> > > --Gunnar > > On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling >> wrote: >> >>> Hi John, >>> >>> 2014-09-09 10:33 GMT+02:00 John Worrell : >>> Hi Emmanuel & Gunnar, Many thanks for your detailed responses - and nice to chat with Gunnar a week or so back. Again I have to apologise for radio silence - my day job suddenly ate all my waking functional time - so progress has been very slow. >>> >>> No worries, we are very glad about your help. >>> >>> I'm getting deeper into the code now, and starting a POC... which is leading me to some more detailed questions. Basically, what I am doing is to run the examples and to look at things that seem to be missing, and toi understand the data that is being passed around in the various options classes, so I can make a more informed implementation >>> >>> Sounds very reasonable. I also can recommend to take a look at the >>> MongoDB dialect and the persistent representations it creates in the >>> datastore as it can comfortably be browsed e.g. using the mongo command >>> line client. That's how I got to understand many things of the interaction >>> between engine and dialects. >>> >>> If you have any ideas where the dialect SPI documentation can be >>> improved to facilitate an easier understanding of how pieces work together, >>> let me know. >>> >>> The key question in my mind at the moment is that of the relationship between the base Hibernate Dialect class and the GridDialect interface >>> >>> >>> OGM has its own pseudo implementation of ORM's Dialect contract, >>> OgmDialect, but this should hardly ever play a role during OGM development. >>> OGM's main contract towards dialects is GridDialect. >>> >>> The reason for exposing GridDialect on the pseudo OgmDialect is that it >>> is our backdoor to make GridDialect available to >>> PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to >>> inject the GridDialect in a more straight-forward way due to some >>> limitations in the way we integrate with the ORM engine. >>> >>> - I look at the OgmTableGenerator which is attempting to access a CF / table that is not yet created - I figured I understand what was happening here, and make appropriate extensions / fixes first. So, currently fighting my way through generating the sequence tables, and wondering why OgmSequnceGenerator wraps OgmtableGenerator. >>> >>> Just to be sure, are you looking at the latest master? There have been >>> some changes around these generator classes recently, they are in a much >>> cleaner state than they used to be. >>> >>> The reason for the wrapping is that when using the SEQUENCE strategy in >>> cases where the store actually does not natively support sequences, we fall >>> back to TABLE. Currently we only support a "native" SEQUENCE strategy for >>> Neo4j which allows to map sequences as nodes in a reasonable manner, >>> whereas all the other dialects use the table fallback. >>> GridDialect#supportsSequences() is evaluated to find out whether the >>> delegation needs to be done or not. >>> >>> You also could take a look at Neo4jSequenceGenerator which creates the >>> sequence nodes in the datastore based on the registered >>> PersistentNoSqlIdentifierGenerators. Note that this checks via instanceof >>> for OgmSequenceGenerator/OgmTableGenerator atm. As we don't want to expose >>> these types on the dialect SPI, I'm looking into ways for allowing the >>> distinction of the two in a more abst
Re: [hibernate-dev] Contributing to OGM / Cassandra
Hi, 2014-09-09 12:55 GMT+02:00 John Worrell : > Hi Gunnar, > > Wrt the tags - partly it is an issue with Eclipse JPA which > complains if the tags are absent, but I think it *may* actually not > make any difference to the examples - the real issue lies with the code not > picking up the sequences to generate properly, and as you point out that > may now be fixed in the latest master. > To provide some more details, it's a dialect-specific implementation of the SchemaDefiner contract which is in charge of the schema initialization. The specific implementation type is to be returned from DatastoreProvider#getSchemaDefinerType(). The SchemaDefiner is invoked by the engine after session factory initialization (eventually it will only be invoked if required so by the "hbm2ddl.auto" setting). That contract is still experimental at this time, we need to flesh it out in more detail, also based on the feedback what's needed for Cassandra (as it is the first store with a fixed schema). Does Cassandra have any counterpart to physical sequences as e.g. in Oracle? If not (and it can not be emulated in a meaningful way as we do for Neo4j), GridDialect#supportsSequences() would have to return false, and the table-based strategy needs to be implemented. I'll look at a rebase. > > Thanks, > > John > Hth, --Gunnar > On Tue, Sep 9, 2014 at 10:36 AM, Gunnar Morling > wrote: > >> Hi, >> >> 2014-09-09 11:08 GMT+02:00 John Worrell : >> >>> Hi Gunnar, >>> >>> Many thanks for the reply - I'll yank down the master... assume it is >>> merged back to the Jon Halliday fork otherwise I'll need to mess about a >>> bit. >>> >> >> Not sure when Jon's branch was updated for the last time. >> >> Probably you need to rebase (we prefer to work with rebases rather than >> merge commits) your local branch onto the latest master from upstream. >> There have been some changes around GridDialect in the last time, mainly >> about query execution and id generation. Nothing dramatic, though. >> >> >>> Also had some issues with getting connected to C*, understandable, but >>> also wrt adding tags for the Dog / Breed classes in the >>> persistence.xml file. not sure whether that is intended to be needed. >>> >> >> You mean the classes from the "Getting Started" example, right? The >> tags should not be required, the example runs as is e.g. on >> Infinispan. What happens if you don't add those? >> >> Cheers, >>> >>> John >>> >> >> --Gunnar >> >> On Tue, Sep 9, 2014 at 9:59 AM, Gunnar Morling >>> wrote: >>> Hi John, 2014-09-09 10:33 GMT+02:00 John Worrell : > Hi Emmanuel & Gunnar, > > Many thanks for your detailed responses - and nice to chat with Gunnar > a > week or so back. Again I have to apologise for radio silence - my day > job > suddenly ate all my waking functional time - so progress has been very > slow. > No worries, we are very glad about your help. I'm getting deeper into the code now, and starting a POC... which is > leading me to some more detailed questions. Basically, what I am doing > is > to run the examples and to look at things that seem to be missing, and > toi > understand the data that is being passed around in the various options > classes, so I can make a more informed implementation > Sounds very reasonable. I also can recommend to take a look at the MongoDB dialect and the persistent representations it creates in the datastore as it can comfortably be browsed e.g. using the mongo command line client. That's how I got to understand many things of the interaction between engine and dialects. If you have any ideas where the dialect SPI documentation can be improved to facilitate an easier understanding of how pieces work together, let me know. The key question in my mind at the moment is that of the relationship > between the base Hibernate Dialect class and the GridDialect interface OGM has its own pseudo implementation of ORM's Dialect contract, OgmDialect, but this should hardly ever play a role during OGM development. OGM's main contract towards dialects is GridDialect. The reason for exposing GridDialect on the pseudo OgmDialect is that it is our backdoor to make GridDialect available to PersistentNoSqlIdentifierGenerator implementations. Atm. there is no way to inject the GridDialect in a more straight-forward way due to some limitations in the way we integrate with the ORM engine. > - I > look at the OgmTableGenerator which is attempting to access a CF / > table > that is not yet created - I figured I understand what was happening > here, > and make appropriate extensions / fixes first. So, currently fighting > my > way through generating the sequence tables, and wondering why > OgmSequnceGenerator wraps OgmtableGenerator. > Just
