Re: [hibernate-dev] [ORM] Reducing startup log verbosity
+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 ___ 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
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 > ___ 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
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. 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. 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. 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 > > > ___ > 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] Default access type and MappedSuperclass
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
