Re: [hibernate-dev] 6.0 - concept naming
the proposal, names and structure, looks good to me.
I would just change, in the SecondaryTableBinding, the attribute name
"predicate" to "foreignKey"
On 14 April 2017 at 18:24, Steve Ebersole wrote:
> Before I get deeper into this persister work I wanted to discuss some of
> the primary design concepts and start a discussion about naming the
> interfaces/classes related to them.
>
> I am thinking it would be best to model the tables associated with a
> persister using a similar structure we use for
> TableSpace/TableGroup/TableGroupJoin but in the non-specific-reference
> case. For example, the Person entity might be mapped to 2 tables: the
> primary PERSON table, and a PERSON_SUPP secondary table. Inside the
> persister we'd map the binding to those tables including the join criteria
> between them. This is distinctly different from the structure of
> references to those tables as part of a specific query. So inside
> persister we'd map a structure like:
>
> EntityPersister {
> ...
> rootTable = Table( PERSON )
> secondaryTables = {
> SecondaryTableBinding {
> joinType = INNER
> targetTable = Table( PERSON_SUPP )
> predicate = {
> EQ {
> lhs = {
> ColumnBinding( Column( Table( PERSON ), "id" )
> }
> rhs = {
> ColumnBinding( Column( Table( PERSON_SUPP ), "p_id"
> )
> }
> }
> }
> }
> }
>
> We could simplify this if we follow the same assumption we do today that
> the secondary tables always use the root table as the lhs. Additionally we
> might consider simplifying the join predicate to use the ForeignKey which
> already defines this join predicate info:
>
> EntityPersister {
> ...
> rootTable = Table( PERSON )
> secondaryTables = {
> SecondaryTableBinding {
> joinType = INNER
> targetTable = Table( PERSON_SUPP )
> predicate = ForeignKey {
> uid = 123456789ABC
> ...
> }
> }
> }
> }
>
>
> Compare this to the structure for a particular query[1], which is
> different:
>
> TableGroup
> root = TableReference {
> table = ( Table( PERSON ) )
> identifiactionVariable = p0
> tableJoins = {
> TableReferenceJoin {
> ...
> }
> }
> }
> }
>
> Notice specifically the addition of the identifactionVariable (alias).
> Because we might have multiple references to that same table which need to
> be unique in the given query, e.g. a fetched or joined self-referential
> association (person -> manager).
>
> First, what do you think of these proposed structures? And secondly what
> are y'alls opinions wrt the names?
>
> FWIW there are 2 main reasons I propose modeling things the way I suggest
> above in terms of the structure on persisters:
>
>1. I think it makes it easier for consumers of persisters to understand
>the bindings
>2. I *think* (tbd) that it makes it easier to "clone" into the query
>TableGroup structure.
>
> Anyway, would love feedback on this.
>
> [1] Note that the class called `TableReference` here is called
> `TableBinding` in the currently pushed code, but I'd prefer to change that
> and instead have "binding" term reference the binding of the table in the
> persister model. I am open to different naming here though.
> ___
> 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] CI Updates on the 20th of April
I will run some updates on Jenkins next Thursday (20th of April). This should remove the red Warning one sees when logged in. Problem is that some plugins changed the way they store configuration and it might affects some jobs. Thanks, Davide ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Hibernat OGM contrib repository
On 17 April 2017 at 16:32, Davide D'Alto wrote: > If I understand correctly the consensus for the contrib dialects is: > > * Keep the same group id of core: org.hibernate.ogm > * Keep the same license we use in OGM > * Create a repository per dialect: each repository will have it's own > life-cycle, it will depend on core and it won't impact the other > dialects. > > I'm not sure if I like the idea to have a repository per dialect in > term of maintenance but it seems the most flexible approach. > > Would that work for everybody? Looks good to me! Thanks, Sanne > > Thanks, > Davide > > On Tue, Apr 11, 2017 at 10:39 AM, Sanne Grinovero wrote: >> On 11 April 2017 at 10:24, Gunnar Morling wrote: >>> Hi, >>> >>> On the group id, I'd prefer to keep it as is. This will make it less >>> disruptive if dialects are demoted/promoted between contrib and core. >>> On the license I also think it needs to remain as is. >> >> +1 >> >>> Overall, I'm still unsure what's the implication of the split and how >>> the lifecycle of dialects is going to look like. Will there be a >>> release of the contrib repo's dialects whenever core is released? What >>> does it mean if a dialect is in contrib? Will it be ensured that it >>> generally works with the latest OGM, but it will not benefit from any >>> new optimizations in core? How will people know which versions work >>> together? >> >> This is very important to clarify, as it's supposed to be "the" reason >> for the split. >> >> As far as I understood from our previous debates, the problem being >> addressed is that we have no bandwidth / interest in maintaining all >> of them. >> So if that's the case, I believe it's important that *we will allow* >> for the main repository to go ahead with new development and releases >> while not necessarily bringing the contrib dialects on par. >> >> This implies that the "contrib" dialects will not necessarily be >> released for each latest version of OGM and there might be gaps in >> compatibility. >> >> The problem I see with this, is that not all "contrib dialects" will >> be equal. So while someone might want to volunteer to bring dialect A >> up to speed with latest OGM versions, they will want to see it >> released and yet we might not have been able to update the other >> dialects in the contrib repository: the other dialects being in bad >> state shouldn't block the ones ready for a release. >> >> So we need to be able to release each contrib dialect independently. I >> probably wouldn't use a single repository for them, this clearly is a >> set of different projects depending on OGM/core. >> >>> >>> I'd probably be a good idea to have a document describing the policies >>> and lifecycles around these modules and the repo split. >> >> +1 >> >>> Did you take a look at how it's done in Spring Data btw.? There they >>> have a repo per datastore, each with their own release cycle AFAIKU. >>> And then there are "release trains", which essentially is a family of >>> releases of the datastores, with all matching versions grouped in a >>> BOM. >> >> BOMs are dead. Long live modules! >> >> >> >> +1 for trains, but allow gaps please. >> For example there might be no interest in getting all dialects updated >> for 5.2 - while they existed for 5.1 - and yet someone might want to >> restore some of them for 5.3. >> >>> That model seems the most flexible in terms of independent releases, >>> and it'd also allow to abandon a specific datastore if no one steps up >>> to maintain it (by excluding it from the next release train), but I >>> could imagine the plethora of repos and required releases doesn't make >>> it easy to manage necessarily. >> >> Thanks, >> Sanne >> >> >>> >>> --Gunnar >>> >>> >>> >>> 2017-03-28 13:08 GMT+02:00 Sanne Grinovero : Regarding the License I think we have no choice, we have to use the same license as alternatively we'd need to get permission to change the license as it's existing code. I'm assuming we have no interest in that, and if we had this process would take some time so we'd have to propose such a change as an independent step from the repository move. Regarding group-id : I see no reason to change it but have no strong opinion on that. I'd similarly suggest to make such changes as a follow-up though, and not treat it as a blocker. (If we decide to change it, it would be a breaking change so we'd need redirection poms so we might as well do it later) Thanks, Sanne On 28 March 2017 at 11:28, Davide D'Alto wrote: > Hi all, > I've moved the contributed dialect for OGM in this repository: > https://github.com/DavideD/hibernate-ogm-contrib > > I have a couple of quesitons before moving it in an official repository: > > - Which group id should we use? At the moment it is still > org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib > > - What about the license? Can I re-us
[hibernate-dev] Negative sequence numbers
I see a comment on HHH-10219 that sounds like negative sequence values are
supported by NoopOptimizer [1], but it does not seem to work.
I've pushed a test case to my fork [2] with an entity defined as:
@Entity( name = "TheEntity" )
@Table( name = "TheEntity" )
public static class TheEntity {
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
"ID_GENERATOR")
@SequenceGenerator(name = "ID_GENERATOR", sequenceName =
"ENTITY_SEQ", initialValue= -10, allocationSize = -1)
public Integer id;
}
The first generated value is -10; the second generated value should be -11,
but it is -9.
The sequence is exported as:
create sequence ENTITY_SEQ start with -10 increment by 1
In the debugger, I can see that NoopOptimizer is being used, which has the
correct incrementSize (-1).
The problem is that SequenceStructure#getSourceIncrementSize always returns
1. This is because SequenceStructure#applyIncrementSizeToSourceValues gets
initialized to false because NoopOptimizer#applyIncrementSizeToSourceValues
returns false. [3]
If I change NoopOptimizer#applyIncrementSizeToSourceValues to return true,
then the test passes. Unfortunately, SequenceHiLoGeneratorNoIncrementTest
fails though because Hibernate tries to create a sequence that increments
by 0.
If I define NoopOptimizer#applyIncrementSizeToSourceValues as follows, both
my test [2] and SequenceHiLoGeneratorNoIncrementTest pass.
public boolean applyIncrementSizeToSourceValues() {
return getIncrementSize() != 0;
}
Should Hibernate support negative sequence values?
If so, is my proposed fix OK?
Regards,
Gail
[1]
https://hibernate.atlassian.net/browse/HHH-10219?focusedCommentId=73362&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-73362
[2] https://github.com/gbadner/hibernate-core/tree/negative-sequence-values
[3]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/id/enhanced/SequenceStructure.java#L162-L164
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
