Re: [hibernate-dev] Changing group ids from org.hibernate to org.hibernate.{project}
On 6 October 2016 at 07:26, Gunnar Morling wrote: >> Thinking about it more though, don't we have that problem anyway since we >> still want to publish relocation artifacts? > > Do we need to create relocation artifacts for new modules only added after > the group id change? There won't be wrong references to these out in the > wild, so people should be fine without them? What Steve (rightfully) suggests is that the relocation artifacts will have the old groupIds, so we would still be publishing new artifacts using the old ids, and will need to accommodate for that in any synchronisation rules. > Either way I think if ORM changes it in 6, we should do it consistently for > HV/HSEARCH, too, as it will be less confusing down the road. +1 > > 2016-10-06 4:10 GMT+02:00 Steve Ebersole : >> >> To clarify my last reply... >> >> Today all of the artifacts under org.hibernate are published to JBoss >> Nexus >> and then rsync'ed to Central. When I move to publishing the artifacts for >> ORM to Central "directly" (via OSSRH), those artifacts need to be excluded >> from the rsync. But today, because all (most) of the projects use >> org.hibernate as the groupId there is no single directory I can say to >> exclude. Instead we'd have to list the ORM artifacts explicitly, >> individually. The problem ofc being when we add a new module to ORM we'd >> have to remember to add that to the list of exclusions. >> >> Thinking about it more though, don't we have that problem anyway since we >> still want to publish relocation artifacts? >> >> On Wed, Oct 5, 2016 at 8:04 PM Steve Ebersole wrote: >> >> > It's more a convenience of defining the rsync that currently happens >> > between JBoss and Central. >> > >> > On Wed, Oct 5, 2016, 5:48 PM Sanne Grinovero >> > wrote: >> > >> > Are we required to change groupId for that? >> > Asking mainly to get OGM there as well, as it's already using the >> > proposed >> > scheme. >> > >> > On Wed, 5 Oct 2016, 23:44 Steve Ebersole, wrote: >> > >> > The grouping is certainly "nice". But given the possibility of >> > difficulties renaming the groupId could have for users I'd not make this >> > change just because it is nice. No, this is part of a larger change I >> > want >> > to do which is laid out in the JIRA Gunnar mentioned. Specifically I >> > want >> > to move away from publishing to JBoss Nexus and instead publish directly >> > to >> > Sonatype's OSSRH offering. >> > >> > On Wed, Oct 5, 2016, 5:32 PM Max Rydahl Andersen >> > wrote: >> > >> > yes, with relocation artefacts things could be made less annoying. >> > >> > Just wanted to be sure we at least considered it and I hope you can get >> > Gradle to play nice ;) >> > >> > /max >> > >> > > Hi Max, >> > > >> > > the intent is to publish "relocation artifacts" like this one which we >> > > created when the Hibernate Search main artifact was renamed from >> > > "org.hibernate:hibernate-search" to >> > > "org.hibernate:hibernate-search-orm" >> > > >> > > >> > >> > https://raw.githubusercontent.com/hibernate/hibernate-search/master/legacy/pom.xml >> > > >> > > If the tool in question respects the Maven relocation rules, when >> > > consuming the old coordinates you'd get a warning and be transparently >> > > served the new coordinates. Maven itself works fine with this, I don't >> > > know about other tools.. I've heard no complaints from the Search >> > > users but of course that's a smaller population and not many tools >> > > AFAIK, so I'm looking forward for feedback on more specific problems. >> > > >> > > It's not clear yet however if we'll actually do this and for how long, >> > > as e.g. Gradle seems to not be able to produce these so we'll need to >> > > possibly hack a custom plugin for this? >> > > >> > > In the chat with Steve yesterday we both agreed that we shouldn't do >> > > this forever, but to treat it like a deprecated method; so it seems >> > > sensible to keep it for the lifetime of ORM 6.x. >> > > In the case of the above Search example we kept it for longer, as it's >> > > doing no harm and is not in the way as much as maintaining deprecated >> > > code could be. >> > > >> > > I actually have one concern, after a night of sleep :) >> > > This might be just something that *we* like to see as maintainer in >> > > terms of order, but I'm wondering if this organization makes sense for >> > > end users. Considering the "groupId" to be pretty much an >> > > "organization id", I'd wager that consumers see us as one consistent >> > > entity, and we'd be possibly damaging the brand. >> > > >> > > We keep some of our projects in separate repositories as it would >> > > otherwise be too much maintenance and synchronization work, but >> > > several users have expressed that this is confusing and they'd rather >> > > see us, among others, align version numbers and release schedules. >> > > >> > > Also I guess one reason for the "groupId" to exist at all is to help >> > > ensuring uniqueness of artifact ids among t
Re: [hibernate-dev] SQM - encoding type info into the tree
I'm inclined towards the second option but not sure if it can have
limitations compared to the first one.
On 5 October 2016 at 22:59, Steve Ebersole wrote:
> In SQM's domain metamodel we decided to follow JPA's guidelines in terms
> of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM
> describes a Java type not its database mapping, just as it is in JPA.
>
> As a concrete example of the difference and its implication, consider a
> Boolean attribute. The Type for that attribute would be
> a BasicType which only describes the Java Boolean type; it
> contains no information about how that value is mapped to the database (aka
> it is not a "mapping type"). But this mapping information is important.
> It is simply not enough to know that the value is a Boolean, we have to
> know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a
> CHAR(1)" etc.
>
> As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve
> domain metamodel info for us. The ideal being that as as we build the SQM
> tree in SQM we could encode "mapping type" information from the consumer
> into the tree structure. But the problem is how to define access to a
> "mapped type system" when SQM's type system is strictly domain-based.
>
> Where this really becomes problematic is when determining the "implicit
> type" for Expression nodes in the tree. Consider an example...
>
> {code}
> from Person p where p.active = ?1
> {code}
>
> The idea is that we really want to be able to infer the type of the "?1"
> parameter expression based on its context in the query. Since it is used
> as an operand of a equality predicate we know that its type should be the
> same as the other operand, here: "p.active".
>
> But this is where the domain-type/mapping-type split comes into play. At
> the SQM level we have no notion of a "mapping type", so the fact that
> "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a
> CHAR(1)", which is really the information we want associated with the param
> expression. All we can know from the SQM side is that "p.active" is a
> BasicType and therefore "?1" should be to - but that is not enough
> contextual info to handle binding that param properly.
>
> I see a few options to address this:
>
>1. Add a notion of "mapping type" to SQM's domain metamodel. The
>"mapping type" would not be ORM-specific (aka, no expectation of JDBC).
>Think of it more as a momento (pattern). This effectively creates a
>complete parallel of ORM's type system though, which always feels like a
>code smell to me.
>2. Simply leave determination of an expression's "implicit type" out of
>SQM. Resolving an expression's implicit type based on Type as defined
> by
>JPA and currently by SQM is simply not expressive enough to be of any
>value. As the SQM consumer processes the SQM tree it would make that
>determination then.
> ___
> 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] SQM - encoding type info into the tree
Well there is then the ideological argument about this being a *semantic*
query tree. I'd argue that resolving non-explicit types is part of that
process. But if the semantic interpretation does not understand that more
contextual type system, then there is not really much to do.
I don't think we lose anything. We'd just do it later.
On Thu, Oct 6, 2016 at 9:41 AM andrea boriero wrote:
> I'm inclined towards the second option but not sure if it can have
> limitations compared to the first one.
>
> On 5 October 2016 at 22:59, Steve Ebersole wrote:
>
> In SQM's domain metamodel we decided to follow JPA's guidelines in terms
> of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM
> describes a Java type not its database mapping, just as it is in JPA.
>
> As a concrete example of the difference and its implication, consider a
> Boolean attribute. The Type for that attribute would be
> a BasicType which only describes the Java Boolean type; it
> contains no information about how that value is mapped to the database (aka
> it is not a "mapping type"). But this mapping information is important.
> It is simply not enough to know that the value is a Boolean, we have to
> know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a
> CHAR(1)" etc.
>
> As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve
> domain metamodel info for us. The ideal being that as as we build the SQM
> tree in SQM we could encode "mapping type" information from the consumer
> into the tree structure. But the problem is how to define access to a
> "mapped type system" when SQM's type system is strictly domain-based.
>
> Where this really becomes problematic is when determining the "implicit
> type" for Expression nodes in the tree. Consider an example...
>
> {code}
> from Person p where p.active = ?1
> {code}
>
> The idea is that we really want to be able to infer the type of the "?1"
> parameter expression based on its context in the query. Since it is used
> as an operand of a equality predicate we know that its type should be the
> same as the other operand, here: "p.active".
>
> But this is where the domain-type/mapping-type split comes into play. At
> the SQM level we have no notion of a "mapping type", so the fact that
> "p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a
> CHAR(1)", which is really the information we want associated with the param
> expression. All we can know from the SQM side is that "p.active" is a
> BasicType and therefore "?1" should be to - but that is not enough
> contextual info to handle binding that param properly.
>
> I see a few options to address this:
>
>1. Add a notion of "mapping type" to SQM's domain metamodel. The
>
>
>"mapping type" would not be ORM-specific (aka, no expectation of JDBC).
>Think of it more as a momento (pattern). This effectively creates a
>complete parallel of ORM's type system though, which always feels like a
>code smell to me.
>
>2. Simply leave determination of an expression's "implicit type" out of
>
>
>SQM. Resolving an expression's implicit type based on Type as defined
> by
>JPA and currently by SQM is simply not expressive enough to be of any
>value. As the SQM consumer processes the SQM tree it would make that
>determination then.
>
> ___
> 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] Hibernate Search: Triple release!
Hello all, today we published three releases of Hibernate Search: - 5.5.5.Final - 5.6.0.Beta3 - 5.7.0.Alpha1 For more information and an explanation please see our blog: - http://in.relation.to/2016/10/06/TripleHibernateSearchRelease/ Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
