Re: [hibernate-dev] Default access type and MappedSuperclass
Trying to make sure I understand.. so the report is just wrong? Or is
there some difference in your model versus theirs?
On Thu, Jan 10, 2019 at 2:22 PM andrea boriero wrote:
> yes also for the MappedSuperclass
>
> from:
>
> @MappedSuperclass
> public abstract class AbstractCatalogEntity {
> @Column( name = "CODE")
> private String code;
>
> @Column( name = "NAME")
> private String name;
> }
>
> @Entity
> public class CatalogEntity extends AbstractCatalogEntity {
> @Id
> private Long id;
> }
>
> I obtained :
>
> @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
> @StaticMetamodel(AbstractCatalogEntity.class)
> public abstract class AbstractCatalogEntity_ {
>
> public static volatile SingularAttribute
> code;
> public static volatile SingularAttribute
> name;
>
> public static final String CODE = "code";
> public static final String NAME = "name";
>
> }
>
> @Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
> @StaticMetamodel(CatalogEntity.class)
> public abstract class CatalogEntity_ extends
> org.hibernate.userguide.model.AbstractCatalogEntity_ {
>
> public static volatile SingularAttribute id;
>
> public static final String ID = "id";
>
> }
>
>
>
>
> On Thu, 10 Jan 2019 at 11:52, Guillaume Smet
> wrote:
>
> > The generated model of the MappedSuperclass?
> >
> > Because the one of the subclass is correct for sure.
> >
> > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero
> > wrote:
> >
> >> I'm not sure I have fully understood the issue, the @Id may be not
> >> defined in the MappedSuperclass but for sure it must be in the
> subclasses
> >> extending it.
> >>
> >> I have tried and I can reproduce the issue only if I do not specify
> >> any @Id annotation in the subclass, but as soon as I add the @Id to a
> >> subclass of the MappedSuperclass the generated static metamodel is
> correct.
> >>
> >>
> >> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> We recently had this issue opened about us not choosing the right
> access
> >>> type for a mapped super class:
> >>> https://hibernate.atlassian.net/browse/HHH-12938 .
> >>>
> >>> Hibernate currently base the access type decision on the sole placement
> >>> of
> >>> the @Id annotation, which, in the case of a @MappedSuperclass might not
> >>> be
> >>> defined (this is the OP's case).
> >>>
> >>> I closed the issue explaining what we do and pointing a workaround but
> >>> the
> >>> OP rightfully replied with the JPA spec saying "The default access type
> >>> of
> >>> an entity hierarchy is determined by the placement of mapping
> annotations
> >>> on the attributes of the entity classes and mapped superclasses of the
> >>> entity hierarchy that do not explicitly specify an access type".
> >>>
> >>> I'm wondering if we should also consider the @Column annotations
> >>> placement
> >>> if there is no @Id annotation.
> >>>
> >>> If the answer is that it's already fixed in 6, it's all good for me :).
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Guillaume
> >>> ___
> >>> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Reducing startup log verbosity
On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: > On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > > > I disagree that logging a single message is a better solution because > that probably ends up wrapping multiple lines, just as your sample happened > to do in the email. IMO that is actually more difficult to read. > > Ok keep it in one line if you prefer. No strong preference on how it's > presented, but I think it's a big mistake to hide essential > diagnostics: "paste the logs" is often useful when helping someone; it > gets much harder if you first have to change categories. > You are combining separate things here First, *you* are the one that suggested doing it on one line unless I have misunderstood. My point is simply that practically speaking that will either mean having to read wrapped lines (eww) or scroll horizontally (double eww) to read this info. If your desire is to continue present this information anyway, then, well, what exactly are we changing? Just making it harder to read? "Diagnostics".. interesting choice of word... if you are diagnosing something that implies that there is a problem you are debugging... but here we are talking about boot-time informational logging. Different beasts. If the distinction you are trying to make is that we want to see at a glance what config Hibernate thinks it just processed versus what you think it should be (was caching enabled, etc) - well, where do you draw the line? Because this gets back to my first point; if you log everything that is "useful" in this single boot-time log message it is going to be completely unreadable. +1 those symbolic loggers are a great idea. But then please don't hide > this information at least until we have those easier logger > categories: Guillaume is set to patch 5.4x - which doesn't have them > yet. > What I am doing in 6 has no bearing on this discussion. Either we display information or we don't - that is the crux of this discussion, not which logger/category name we use. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Default access type and MappedSuperclass
Yes, we're doing something like that in MapStruct, too: https://github.com/mapstruct/mapstruct/blob/master/processor/src/main/java/org/mapstruct/ap/MappingProcessor.java#L114 There we need to wait with code generation for processed classes until their hierarchy has stabilized (other APs may generate superclasses that we must consider). Perhaps the Code ist helpful to you. --Gunnar Am 10.01.2019 15:01 schrieb "Steve Ebersole" : Hm, seems like the "AP delayed generation" approach is a possibility. From a quick search: https://stackoverflow.com/questions/41874462/java-annotation-process-not-yet-generated-elements https://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/RoundEnvironment.html#processingOver%28%29 Disclaimer - I have not tried this, just read about it... On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole wrote: > This is one of the cases (there are others) where we do not completely > follow the JPA spec. > > TBH I'm not really sure how we would address this in an annotation > processor, though granted my knowledge of those APIs is limited. But as I > understand it we have to generate the metamodel class as we process the > model class without knowledge of or access to other classes. Specifically > here, we see the MappedSuperclasss first as it is a superclass and the > compiler needs to process it first. > > I had planned on re-looking at this in 7 to offer a non-AP solution to > metamodel generation. I don't think anything requires that we support this > through an AP. > > There are other problems using an AP for this, namely it is extremely > difficult to incorporate orm.xml info whether partial or complete. > > I guess a solution for now would involve somehow delaying the generation > of the metamodel classes until the end of the AP cycle which (IIUC) would > only really work with `proc:only` > > On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet > wrote: > >> The generated model of the MappedSuperclass? >> >> Because the one of the subclass is correct for sure. >> >> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero >> wrote: >> >> > I'm not sure I have fully understood the issue, the @Id may be not >> defined >> > in the MappedSuperclass but for sure it must be in the subclasses >> extending >> > it. >> > >> > I have tried and I can reproduce the issue only if I do not specify >> > any @Id annotation in the subclass, but as soon as I add the @Id to a >> > subclass of the MappedSuperclass the generated static metamodel is >> correct. >> > >> > >> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet >> > wrote: >> > >> >> Hi, >> >> >> >> We recently had this issue opened about us not choosing the right >> access >> >> type for a mapped super class: >> >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> >> >> Hibernate currently base the access type decision on the sole >> placement of >> >> the @Id annotation, which, in the case of a @MappedSuperclass might >> not be >> >> defined (this is the OP's case). >> >> >> >> I closed the issue explaining what we do and pointing a workaround but >> the >> >> OP rightfully replied with the JPA spec saying "The default access >> type of >> >> an entity hierarchy is determined by the placement of mapping >> annotations >> >> on the attributes of the entity classes and mapped superclasses of the >> >> entity hierarchy that do not explicitly specify an access type". >> >> >> >> I'm wondering if we should also consider the @Column annotations >> placement >> >> if there is no @Id annotation. >> >> >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> >> >> Thoughts? >> >> >> >> -- >> >> Guillaume >> >> ___ >> >> 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 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] Default access type and MappedSuperclass
Hm, seems like the "AP delayed generation" approach is a possibility. From a quick search: https://stackoverflow.com/questions/41874462/java-annotation-process-not-yet-generated-elements https://docs.oracle.com/javase/6/docs/api/javax/annotation/processing/RoundEnvironment.html#processingOver%28%29 Disclaimer - I have not tried this, just read about it... On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole wrote: > This is one of the cases (there are others) where we do not completely > follow the JPA spec. > > TBH I'm not really sure how we would address this in an annotation > processor, though granted my knowledge of those APIs is limited. But as I > understand it we have to generate the metamodel class as we process the > model class without knowledge of or access to other classes. Specifically > here, we see the MappedSuperclasss first as it is a superclass and the > compiler needs to process it first. > > I had planned on re-looking at this in 7 to offer a non-AP solution to > metamodel generation. I don't think anything requires that we support this > through an AP. > > There are other problems using an AP for this, namely it is extremely > difficult to incorporate orm.xml info whether partial or complete. > > I guess a solution for now would involve somehow delaying the generation > of the metamodel classes until the end of the AP cycle which (IIUC) would > only really work with `proc:only` > > On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet > wrote: > >> The generated model of the MappedSuperclass? >> >> Because the one of the subclass is correct for sure. >> >> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero >> wrote: >> >> > I'm not sure I have fully understood the issue, the @Id may be not >> defined >> > in the MappedSuperclass but for sure it must be in the subclasses >> extending >> > it. >> > >> > I have tried and I can reproduce the issue only if I do not specify >> > any @Id annotation in the subclass, but as soon as I add the @Id to a >> > subclass of the MappedSuperclass the generated static metamodel is >> correct. >> > >> > >> > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet >> > wrote: >> > >> >> Hi, >> >> >> >> We recently had this issue opened about us not choosing the right >> access >> >> type for a mapped super class: >> >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> >> >> Hibernate currently base the access type decision on the sole >> placement of >> >> the @Id annotation, which, in the case of a @MappedSuperclass might >> not be >> >> defined (this is the OP's case). >> >> >> >> I closed the issue explaining what we do and pointing a workaround but >> the >> >> OP rightfully replied with the JPA spec saying "The default access >> type of >> >> an entity hierarchy is determined by the placement of mapping >> annotations >> >> on the attributes of the entity classes and mapped superclasses of the >> >> entity hierarchy that do not explicitly specify an access type". >> >> >> >> I'm wondering if we should also consider the @Column annotations >> placement >> >> if there is no @Id annotation. >> >> >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> >> >> Thoughts? >> >> >> >> -- >> >> Guillaume >> >> ___ >> >> 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Default access type and MappedSuperclass
This is one of the cases (there are others) where we do not completely follow the JPA spec. TBH I'm not really sure how we would address this in an annotation processor, though granted my knowledge of those APIs is limited. But as I understand it we have to generate the metamodel class as we process the model class without knowledge of or access to other classes. Specifically here, we see the MappedSuperclasss first as it is a superclass and the compiler needs to process it first. I had planned on re-looking at this in 7 to offer a non-AP solution to metamodel generation. I don't think anything requires that we support this through an AP. There are other problems using an AP for this, namely it is extremely difficult to incorporate orm.xml info whether partial or complete. I guess a solution for now would involve somehow delaying the generation of the metamodel classes until the end of the AP cycle which (IIUC) would only really work with `proc:only` On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet wrote: > The generated model of the MappedSuperclass? > > Because the one of the subclass is correct for sure. > > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero > wrote: > > > I'm not sure I have fully understood the issue, the @Id may be not > defined > > in the MappedSuperclass but for sure it must be in the subclasses > extending > > it. > > > > I have tried and I can reproduce the issue only if I do not specify > > any @Id annotation in the subclass, but as soon as I add the @Id to a > > subclass of the MappedSuperclass the generated static metamodel is > correct. > > > > > > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet > > wrote: > > > >> Hi, > >> > >> We recently had this issue opened about us not choosing the right access > >> type for a mapped super class: > >> https://hibernate.atlassian.net/browse/HHH-12938 . > >> > >> Hibernate currently base the access type decision on the sole placement > of > >> the @Id annotation, which, in the case of a @MappedSuperclass might not > be > >> defined (this is the OP's case). > >> > >> I closed the issue explaining what we do and pointing a workaround but > the > >> OP rightfully replied with the JPA spec saying "The default access type > of > >> an entity hierarchy is determined by the placement of mapping > annotations > >> on the attributes of the entity classes and mapped superclasses of the > >> entity hierarchy that do not explicitly specify an access type". > >> > >> I'm wondering if we should also consider the @Column annotations > placement > >> if there is no @Id annotation. > >> > >> If the answer is that it's already fixed in 6, it's all good for me :). > >> > >> Thoughts? > >> > >> -- > >> Guillaume > >> ___ > >> 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Default access type and MappedSuperclass
yes also for the MappedSuperclass
from:
@MappedSuperclass
public abstract class AbstractCatalogEntity {
@Column( name = "CODE")
private String code;
@Column( name = "NAME")
private String name;
}
@Entity
public class CatalogEntity extends AbstractCatalogEntity {
@Id
private Long id;
}
I obtained :
@Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
@StaticMetamodel(AbstractCatalogEntity.class)
public abstract class AbstractCatalogEntity_ {
public static volatile SingularAttribute
code;
public static volatile SingularAttribute
name;
public static final String CODE = "code";
public static final String NAME = "name";
}
@Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
@StaticMetamodel(CatalogEntity.class)
public abstract class CatalogEntity_ extends
org.hibernate.userguide.model.AbstractCatalogEntity_ {
public static volatile SingularAttribute id;
public static final String ID = "id";
}
On Thu, 10 Jan 2019 at 11:52, Guillaume Smet
wrote:
> The generated model of the MappedSuperclass?
>
> Because the one of the subclass is correct for sure.
>
> On Thu, Jan 10, 2019 at 12:44 PM andrea boriero
> wrote:
>
>> I'm not sure I have fully understood the issue, the @Id may be not
>> defined in the MappedSuperclass but for sure it must be in the subclasses
>> extending it.
>>
>> I have tried and I can reproduce the issue only if I do not specify
>> any @Id annotation in the subclass, but as soon as I add the @Id to a
>> subclass of the MappedSuperclass the generated static metamodel is correct.
>>
>>
>> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet
>> wrote:
>>
>>> Hi,
>>>
>>> We recently had this issue opened about us not choosing the right access
>>> type for a mapped super class:
>>> https://hibernate.atlassian.net/browse/HHH-12938 .
>>>
>>> Hibernate currently base the access type decision on the sole placement
>>> of
>>> the @Id annotation, which, in the case of a @MappedSuperclass might not
>>> be
>>> defined (this is the OP's case).
>>>
>>> I closed the issue explaining what we do and pointing a workaround but
>>> the
>>> OP rightfully replied with the JPA spec saying "The default access type
>>> of
>>> an entity hierarchy is determined by the placement of mapping annotations
>>> on the attributes of the entity classes and mapped superclasses of the
>>> entity hierarchy that do not explicitly specify an access type".
>>>
>>> I'm wondering if we should also consider the @Column annotations
>>> placement
>>> if there is no @Id annotation.
>>>
>>> If the answer is that it's already fixed in 6, it's all good for me :).
>>>
>>> Thoughts?
>>>
>>> --
>>> Guillaume
>>> ___
>>> 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] Default access type and MappedSuperclass
The generated model of the MappedSuperclass? Because the one of the subclass is correct for sure. On Thu, Jan 10, 2019 at 12:44 PM andrea boriero wrote: > I'm not sure I have fully understood the issue, the @Id may be not defined > in the MappedSuperclass but for sure it must be in the subclasses extending > it. > > I have tried and I can reproduce the issue only if I do not specify > any @Id annotation in the subclass, but as soon as I add the @Id to a > subclass of the MappedSuperclass the generated static metamodel is correct. > > > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet > wrote: > >> Hi, >> >> We recently had this issue opened about us not choosing the right access >> type for a mapped super class: >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> Hibernate currently base the access type decision on the sole placement of >> the @Id annotation, which, in the case of a @MappedSuperclass might not be >> defined (this is the OP's case). >> >> I closed the issue explaining what we do and pointing a workaround but the >> OP rightfully replied with the JPA spec saying "The default access type of >> an entity hierarchy is determined by the placement of mapping annotations >> on the attributes of the entity classes and mapped superclasses of the >> entity hierarchy that do not explicitly specify an access type". >> >> I'm wondering if we should also consider the @Column annotations placement >> if there is no @Id annotation. >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> Thoughts? >> >> -- >> Guillaume >> ___ >> 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] Default access type and MappedSuperclass
I'm not sure I have fully understood the issue, the @Id may be not defined in the MappedSuperclass but for sure it must be in the subclasses extending it. I have tried and I can reproduce the issue only if I do not specify any @Id annotation in the subclass, but as soon as I add the @Id to a subclass of the MappedSuperclass the generated static metamodel is correct. On Thu, 10 Jan 2019 at 11:04, Guillaume Smet wrote: > Hi, > > We recently had this issue opened about us not choosing the right access > type for a mapped super class: > https://hibernate.atlassian.net/browse/HHH-12938 . > > Hibernate currently base the access type decision on the sole placement of > the @Id annotation, which, in the case of a @MappedSuperclass might not be > defined (this is the OP's case). > > I closed the issue explaining what we do and pointing a workaround but the > OP rightfully replied with the JPA spec saying "The default access type of > an entity hierarchy is determined by the placement of mapping annotations > on the attributes of the entity classes and mapped superclasses of the > entity hierarchy that do not explicitly specify an access type". > > I'm wondering if we should also consider the @Column annotations placement > if there is no @Id annotation. > > If the answer is that it's already fixed in 6, it's all good for me :). > > Thoughts? > > -- > Guillaume > ___ > 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] [ORM] Reducing startup log verbosity
On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > I disagree that logging a single message is a better solution because that > probably ends up wrapping multiple lines, just as your sample happened to do > in the email. IMO that is actually more difficult to read. Ok keep it in one line if you prefer. No strong preference on how it's presented, but I think it's a big mistake to hide essential diagnostics: "paste the logs" is often useful when helping someone; it gets much harder if you first have to change categories. > And I just do not understand this idea that we have to direct people to > enable logging to track down problems. This is a non-argument to me. I can understand were you're coming from, but that's how most support people work. Let's try to be nice to them :) > As for what logger to use... that is definitely a concern, though its not > really any different than we have today. If I refactor an internal class > (because, well, its internal) - that almost always will affect logging on the > user's end. It's one of the reasons I started looking at using "symbolic" > logger names. Which of course is its own concern. +1 those symbolic loggers are a great idea. But then please don't hide this information at least until we have those easier logger categories: Guillaume is set to patch 5.4x - which doesn't have them yet. Thanks, Sanne > > On Wed, Jan 9, 2019 at 12:54 PM Guillaume Smet > wrote: >> >> Pretty good idea but definitely too much work for the effort I want to put >> in it right now. >> >> But, yes, we can do that for version 7.0.1.Final, I like your example :). >> >> I will make a proposal to reduce the log verbosity (enhanced classes, >> hibernate.properties missing and a few others) but keep the important >> diagnostic information as is. >> >> On Wed, Jan 9, 2019 at 2:23 PM Sanne Grinovero wrote: >> >> > +1 to polish output, but: >> > >> > I don't want to need to figure out how to reconfigure whatever Logger >> > of the day one happens to hit, to finally notice that essential >> > configuration details are wrong. Mostly because it requires to get the >> > idea to actually check this, which is not a straightforward thought >> > when all you observe is some odd behaviour. >> > >> > Not least, big we don't want to have to go back to supported customers >> > and community members who have a problem with a "can you change the >> > log levels as I'm missing essential information": that's a huge waste >> > of time especially if we're having an exchange across timezones. >> > >> > Could we rather collect essential info and then print it all out as a >> > single message? >> > >> > "Hibernate ORM ready and operational! [version: 7.0.1.Final, >> > Transaction mode: JTA, Dialect: PostgreSQL2020, Caching: enabled]" >> > >> > Also I'd question that "verbosity" isn't the same as brevity; the >> > focus should be on hiding unnecessary technicalities but showing nicer >> > / better information, so I'd not be shy to use some multi-line >> > information box if that looks better. >> > >> > Thanks, >> > Sanne >> > >> > On Mon, 7 Jan 2019 at 16:14, Guillaume Smet >> > wrote: >> > > >> > > Yeah sure, they will be kept as is just moved to DEBUG. >> > > >> > > The only one that would change is the "Processing PersistenceUnitInfo" >> > > thing: we will remove the INFO one and keep the more detailed DEBUG one. >> > > >> > > BTW, I agree with everything Steve said, sorry for not replying earlier. >> > > >> > > On Mon, Jan 7, 2019 at 4:46 PM Chris Cranford >> > wrote: >> > > >> > > > See below. >> > > > >> > > > On 1/3/19 10:29 AM, Steve Ebersole wrote: >> > > > > [o.h.d.Dialect] (main) HHH000400: Using dialect: >> > > > >> org.hibernate.dialect.PostgreSQL95Dialect >> > > > >> >> > > > >> -> wondering if it has any value to log the dialect? I mean if you >> > don't >> > > > >> use the right one, you will definitely have some issues. >> > > > >> >> > > > > True, but it is probably hard(er) to interpret the true source of the >> > > > > issues later on. >> > > > > >> > > > > However, I think it is reasonable to make this DEBUG. If you have >> > > > problems >> > > > > the first reasonable thing to do is to crank logging to DEBUG if not >> > > > TRACE. >> > > > >> > > > I completely agree. >> > > > >> > > > I think its reasonable to make it DEBUG/TRACE but I don't think I want >> > > > to necessarily change it such that it is no longer included in log >> > > > output at all. Having it be included is a good first-line of defense >> > on >> > > > trying to resolve potential problems not only for us, but even for >> > users >> > > > who are doing their own debugging before reporting an issue; >> > > > particularly if the error in question implies some Dialect >> > configuration >> > > > problem. >> > > > >> > > ___ >> > > hibernate-dev mailing list >> > > hibernate-dev@lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
