Re: [hibernate-dev] ORM 5.2 issue with getInterceptor() not being a true getter
Thanks Gail!
On Tue, Sep 12, 2017 at 8:10 AM, Gail Badner wrote:
> I created https://hibernate.atlassian.net/browse/HHH-11982.
>
> I just committed the one-line change without a unit test. Unless I hear
> otherwise, I'll assume that's OK and I'll plan to release on Wednesday,
> 9/13.
>
> Regards,
> Gail
>
> On Mon, Sep 11, 2017 at 10:52 PM, Gail Badner wrote:
>
>> OK, I'll fix it for 5.2.11.
>>
>> Thanks,
>> Gail
>>
>> On Mon, Sep 11, 2017 at 12:20 PM, Steve Ebersole
>> wrote:
>>
>>> I'm fine with that. That method really does not fit with the paradigm
>>> which needs that pulse.
>>>
>>>
>>> On Mon, Sep 11, 2017 at 1:36 PM Sanne Grinovero
>>> wrote:
>>>
>>> > On 11 September 2017 at 16:14, Guillaume Smet <
>>> guillaume.s...@gmail.com>
>>> > wrote:
>>> > > Hi!
>>> > >
>>> > > Any comment on this?
>>> > >
>>> > > After reading the javadoc of SharedSessionContractImplementor, I
>>> think we
>>> > > should probably just get rid of the `checkTransactionSynchStatus();`
>>> call
>>> > > in getInterceptor().
>>> > >
>>> > > I don't think getInterceptor() should be responsible for joining the
>>> > > transaction.
>>> > >
>>> > > What do you all think?
>>> >
>>> > +1
>>> >
>>> > >
>>> > > --
>>> > > Guillaume
>>> > >
>>> > > On Fri, Sep 8, 2017 at 6:26 PM, Guillaume Smet <
>>> guillaume.s...@gmail.com
>>> > >
>>> > > wrote:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> Note to Gail: this is potentially a blocking issue for 5.2.11 for
>>> the
>>> > OGM
>>> > >> upgrade (I thought it was a bug in OGM but apparently, it's an issue
>>> > with
>>> > >> ORM).
>>> > >>
>>> > >> In 5.2 SessionImpl, we now use getInterceptor() instead of
>>> accessing the
>>> > >> interceptor field directly because the field has been moved to
>>> > >> AbstractSharedSessionContract.
>>> > >>
>>> > >> See for instance the change made here in
>>> afterTransactionCompletion():
>>> > >> https://github.com/hibernate/hibernate-orm/blame/master/
>>> > >>
>>> > hibernate-core/src/main/java/org/hibernate/internal/SessionI
>>> mpl.java#L2443
>>> > >>
>>> > >> I think this is an issue as getInterceptor() is not a simple getter
>>> but
>>> > is:
>>> > >> @Override
>>> > >> public Interceptor getInterceptor() {
>>> > >> checkTransactionSynchStatus();
>>> > >> return interceptor;
>>> > >> }
>>> > >>
>>> > >> protected void checkTransactionSynchStatus() {
>>> > >> pulseTransactionCoordinator();
>>> > >> delayedAfterCompletion();
>>> > >> }
>>> > >>
>>> > >> Thus calling the pulse() method of the TransactionCoordinator,
>>> > triggering
>>> > >> an implicit join whereas we're in the afterTransactionCompletion()
>>> > phase.
>>> > >>
>>> > >> This is an issue for us as the pulse() method of our
>>> > >> TransactionCoordinator creates Neo4j transactions so when the
>>> > >> getInterceptor() method is called in afterTransactionCompletion(),
>>> we
>>> > >> create a new Neo4j transaction.
>>> > >>
>>> > >> So 2 questions:
>>> > >> - should we really call checkTransactionSynchStatus(); in
>>> > >> getInterceptor()? If feels a bit weird.
>>> > >> - if so, I think we should have a true protected getter
>>> (interceptor()
>>> > >> following Steve's convention?) to avoid SessionImpl "pulsing" the
>>> > >> transaction coordinator when accessing the interceptor.
>>> > >>
>>> > >> Thanks for your feedback!
>>> > >>
>>> > >> --
>>> > >> 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
[hibernate-dev] [SEARCH] Code style - imports
Hello all, I just noticed that our IDEA codestyle configuration files have specific rules about how to organize imports, whereas the Eclipse ones don't. The most noticeable difference: organizing imports in Eclipse puts static imports at the top, while in IDEA they end up at the bottom. But there are other differences. The Hibernate ORM codebase doesn't seem affected by these inconsistencies (probably because most people working on it use IDEA), but in Hibernate Search we've already reached the point where half of our files follow one convention, and the other half follows the other. What's annoying here is not the inconsistencies themselves (I could live with that), it's more that in the long run we'll end up with tons of unnecessary changes in our commits, due to one person using IDEA to edit a file last edited with Eclipse, and vice-versa. To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot configure Eclipse to match the IDEA style exactly. In particular, we cannot configure where the static imports must go: they will always go to the top ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). I can see two ways out, each with its own drawbacks: - Switch to the "Eclipse" style, and create a Search-specific IDEA code style configuration, with static imports at the top. We won't be consistent with Hibernate ORM, though. - Switch to the "IDEA" style, and create a Search-specific Eclipse code style configuration, as close as the IDEA style as possible. As I said above, automatic import organizing in Eclipse will never follow this style exactly, so it's likely to make organizing imports in Eclipse quite painful. We could add checkstyle rules to make sure we strictly follow the style even in Eclipse. WDYT? Yoann Rodière Hibernate NoORM Team yo...@hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [SEARCH] Code style - imports
Fundamentally no IDE will ever produce exactly the same code so you need to learn control your primal lust for perfection and remember it's not relevant. Have some decency ;) What does actually matter is that we don't keep chaging the order as it introduces conflicts on backporting, it's very annoying and time consuming in the long run. My solution is simple: I don't generally care, BUT commits containing code reformats just for the sake of making one's favourite tool happy need be rejected, especially to stop the bad habit from developing further, or anyone trying to impose its own favourite tool of the day as it was the only blessed way. It's fine if a couple of import reorg "slip in" as part as meaningful changes. The real problem is that applying a patch shouldn't conflict on import statements; ideally there should be a conflict resolution strategy able to understand it better (e.g. teach Java to git tools..) If you want to volunteer making the styles a bit more similar, I typically prefer static imports last. -1 for CheckStyle rules unless you can figure out a way to exclude existing code from failing: we're not going to reformat half the code base to satisfy aesthetics. Perhaps we could have separate sets of rules, some stricter to be applied on new modules; their impact would be limited but even having one module with strict rules would encourage people to reconfigure their IDE in "the right way". This would ensure all new code will be consistent with the rules. Sergey sent a related PR but I'm not sure what to think of it as it changes several things: - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 Thanks, Sanne On 12 September 2017 at 08:42, Yoann Rodiere wrote: > Hello all, > > I just noticed that our IDEA codestyle configuration files have specific > rules about how to organize imports, whereas the Eclipse ones don't. > The most noticeable difference: organizing imports in Eclipse puts static > imports at the top, while in IDEA they end up at the bottom. But there are > other differences. > The Hibernate ORM codebase doesn't seem affected by these inconsistencies > (probably because most people working on it use IDEA), but in Hibernate > Search we've already reached the point where half of our files follow one > convention, and the other half follows the other. > > What's annoying here is not the inconsistencies themselves (I could live > with that), it's more that in the long run we'll end up with tons of > unnecessary changes in our commits, due to one person using IDEA to edit a > file last edited with Eclipse, and vice-versa. > > To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot > configure Eclipse to match the IDEA style exactly. In particular, we cannot > configure where the static imports must go: they will always go to the top ( > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). > > I can see two ways out, each with its own drawbacks: > >- Switch to the "Eclipse" style, and create a Search-specific IDEA code >style configuration, with static imports at the top. We won't be consistent >with Hibernate ORM, though. >- Switch to the "IDEA" style, and create a Search-specific Eclipse code >style configuration, as close as the IDEA style as possible. As I said >above, automatic import organizing in Eclipse will never follow this style >exactly, so it's likely to make organizing imports in Eclipse quite >painful. We could add checkstyle rules to make sure we strictly follow the >style even in Eclipse. > > WDYT? > > > Yoann Rodière > Hibernate NoORM Team > yo...@hibernate.org > ___ > 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] [SEARCH] Code style - imports
Hi, Yes, I had a hard time reverting the import changes in my recent patches for ORM. I was changing only a few lines per file and had a lot of import noise. I would say that it would be nice to have Eclipse and Idea rules as similar as possible. The issue with that is that, for a while, the ORM people will have a lot of import changes, considering we can't make the Eclipse rules Idea like but we can do the opposite. If we don't want to bother the ORM team with that, we should split our rules between ORM and NoORM but it won't be very underestandable for the contributors (but it's not as if we had a lot of them and very few of them find our code styles without us mentioning them). -- Guillaume On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero wrote: > Fundamentally no IDE will ever produce exactly the same code so you > need to learn control your primal lust for perfection and remember > it's not relevant. Have some decency ;) > > What does actually matter is that we don't keep chaging the order as > it introduces conflicts on backporting, it's very annoying and time > consuming in the long run. > > My solution is simple: I don't generally care, BUT commits containing > code reformats just for the sake of making one's favourite tool happy > need be rejected, especially to stop the bad habit from developing > further, or anyone trying to impose its own favourite tool of the day > as it was the only blessed way. > It's fine if a couple of import reorg "slip in" as part as meaningful > changes. > > The real problem is that applying a patch shouldn't conflict on import > statements; ideally there should be a conflict resolution strategy > able to understand it better (e.g. teach Java to git tools..) > > If you want to volunteer making the styles a bit more similar, I > typically prefer static imports last. > > -1 for CheckStyle rules unless you can figure out a way to exclude > existing code from failing: we're not going to reformat half the code > base to satisfy aesthetics. > > Perhaps we could have separate sets of rules, some stricter to be > applied on new modules; their impact would be limited but even having > one module with strict rules would encourage people to reconfigure > their IDE in "the right way". This would ensure all new code will be > consistent with the rules. > > Sergey sent a related PR but I'm not sure what to think of it as it > changes several things: > - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > > Thanks, > Sanne > > > > On 12 September 2017 at 08:42, Yoann Rodiere wrote: > > Hello all, > > > > I just noticed that our IDEA codestyle configuration files have specific > > rules about how to organize imports, whereas the Eclipse ones don't. > > The most noticeable difference: organizing imports in Eclipse puts static > > imports at the top, while in IDEA they end up at the bottom. But there > are > > other differences. > > The Hibernate ORM codebase doesn't seem affected by these inconsistencies > > (probably because most people working on it use IDEA), but in Hibernate > > Search we've already reached the point where half of our files follow one > > convention, and the other half follows the other. > > > > What's annoying here is not the inconsistencies themselves (I could live > > with that), it's more that in the long run we'll end up with tons of > > unnecessary changes in our commits, due to one person using IDEA to edit > a > > file last edited with Eclipse, and vice-versa. > > > > To make the matter worse, Eclipse is not as flexible as IDEA, and we > cannot > > configure Eclipse to match the IDEA style exactly. In particular, we > cannot > > configure where the static imports must go: they will always go to the > top ( > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415). > > > > I can see two ways out, each with its own drawbacks: > > > >- Switch to the "Eclipse" style, and create a Search-specific IDEA > code > >style configuration, with static imports at the top. We won't be > consistent > >with Hibernate ORM, though. > >- Switch to the "IDEA" style, and create a Search-specific Eclipse > code > >style configuration, as close as the IDEA style as possible. As I said > >above, automatic import organizing in Eclipse will never follow this > style > >exactly, so it's likely to make organizing imports in Eclipse quite > >painful. We could add checkstyle rules to make sure we strictly > follow the > >style even in Eclipse. > > > > WDYT? > > > > > > Yoann Rodière > > Hibernate NoORM Team > > yo...@hibernate.org > > ___ > > 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-de
Re: [hibernate-dev] [SEARCH] Code style - imports
> > Fundamentally no IDE will ever produce exactly the same code so you > need to learn control your primal lust for perfection and remember > it's not relevant. Have some decency ;) Sorry if that seemed "indecent", but I did mention that I could live with the inconsistencies, and that what matters is their effect on our git workflow :) If you want to volunteer making the styles a bit more similar, I > typically prefer static imports last. Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try to align the rest of the rules, though. Sergey sent a related PR but I'm not sure what to think of it as it > changes several things: > - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 Yes, it does more than what it advertises, and even the original idea (putting static imports to the top) is not a good idea: ORM already has static imports at the bottom in almost every file, so this change would lead to many more changes than necessary in commits for the ORM project for some time. I would say that it would be nice to have Eclipse and Idea rules as similar > as possible. The issue with that is that, for a while, the ORM people will > have a lot of import changes, considering we can't make the Eclipse rules > Idea like but we can do the opposite. I doubt they'll ever agree with this solution. And I can't blame them. If we don't want to bother the ORM team with that, we should split our > rules between ORM and NoORM but it won't be very underestandable for the > contributors (but it's not as if we had a lot of them and very few of them > find our code styles without us mentioning them). > Seems to be the least disruptive solution. It's not ideal, but it should improve the situation slightly and it wouldn't lead to more changes than necessary in the future git commits. @Sanne this means the imports will stay at the top, though. Ok with that? I'll try to see if I can add non-disruptive checkstyle rules too, if I have some time. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On 12 September 2017 at 11:31, Guillaume Smet wrote: > Hi, > > Yes, I had a hard time reverting the import changes in my recent patches > for ORM. I was changing only a few lines per file and had a lot of import > noise. > > I would say that it would be nice to have Eclipse and Idea rules as > similar as possible. The issue with that is that, for a while, the ORM > people will have a lot of import changes, considering we can't make the > Eclipse rules Idea like but we can do the opposite. > > If we don't want to bother the ORM team with that, we should split our > rules between ORM and NoORM but it won't be very underestandable for the > contributors (but it's not as if we had a lot of them and very few of them > find our code styles without us mentioning them). > > -- > Guillaume > > > On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero > wrote: > >> Fundamentally no IDE will ever produce exactly the same code so you >> need to learn control your primal lust for perfection and remember >> it's not relevant. Have some decency ;) >> >> What does actually matter is that we don't keep chaging the order as >> it introduces conflicts on backporting, it's very annoying and time >> consuming in the long run. >> >> My solution is simple: I don't generally care, BUT commits containing >> code reformats just for the sake of making one's favourite tool happy >> need be rejected, especially to stop the bad habit from developing >> further, or anyone trying to impose its own favourite tool of the day >> as it was the only blessed way. >> It's fine if a couple of import reorg "slip in" as part as meaningful >> changes. >> >> The real problem is that applying a patch shouldn't conflict on import >> statements; ideally there should be a conflict resolution strategy >> able to understand it better (e.g. teach Java to git tools..) >> >> If you want to volunteer making the styles a bit more similar, I >> typically prefer static imports last. >> >> -1 for CheckStyle rules unless you can figure out a way to exclude >> existing code from failing: we're not going to reformat half the code >> base to satisfy aesthetics. >> >> Perhaps we could have separate sets of rules, some stricter to be >> applied on new modules; their impact would be limited but even having >> one module with strict rules would encourage people to reconfigure >> their IDE in "the right way". This would ensure all new code will be >> consistent with the rules. >> >> Sergey sent a related PR but I'm not sure what to think of it as it >> changes several things: >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 >> >> Thanks, >> Sanne >> >> >> >> On 12 September 2017 at 08:42, Yoann Rodiere wrote: >> > Hello all, >> > >> > I just noticed that our IDEA codestyle configuration files have specific >> > rules about how to organize imports, whereas the Eclipse ones don't. >> > The most noticeable difference: organizing imports in Eclipse pu
Re: [hibernate-dev] [SEARCH] Code style - imports
On 12 September 2017 at 10:42, Yoann Rodiere wrote: >> Fundamentally no IDE will ever produce exactly the same code so you >> need to learn control your primal lust for perfection and remember >> it's not relevant. Have some decency ;) > > > Sorry if that seemed "indecent", but I did mention that I could live with > the inconsistencies, and that what matters is their effect on our git > workflow :) > >> If you want to volunteer making the styles a bit more similar, I >> typically prefer static imports last. > > > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try to > align the rest of the rules, though. > >> Sergey sent a related PR but I'm not sure what to think of it as it >> changes several things: >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > > > Yes, it does more than what it advertises, and even the original idea > (putting static imports to the top) is not a good idea: ORM already has > static imports at the bottom in almost every file, so this change would lead > to many more changes than necessary in commits for the ORM project for some > time. > >> I would say that it would be nice to have Eclipse and Idea rules as >> similar as possible. The issue with that is that, for a while, the ORM >> people will have a lot of import changes, considering we can't make the >> Eclipse rules Idea like but we can do the opposite. > > > I doubt they'll ever agree with this solution. And I can't blame them. > >> If we don't want to bother the ORM team with that, we should split our >> rules between ORM and NoORM but it won't be very underestandable for the >> contributors (but it's not as if we had a lot of them and very few of them >> find our code styles without us mentioning them). > > > Seems to be the least disruptive solution. It's not ideal, but it should > improve the situation slightly and it wouldn't lead to more changes than > necessary in the future git commits. > @Sanne this means the imports will stay at the top, though. Ok with that? Yes I'm "ok" with that. But wouldn't it be even better to leave this level of detail undefined? At least it would allow me to make new code having them on the bottom as I like them more, and you'd save some itme :) > > I'll try to see if I can add non-disruptive checkstyle rules too, if I have > some time. > > Yoann Rodière > Hibernate NoORM Team > yo...@hibernate.org > > On 12 September 2017 at 11:31, Guillaume Smet > wrote: >> >> Hi, >> >> Yes, I had a hard time reverting the import changes in my recent patches >> for ORM. I was changing only a few lines per file and had a lot of import >> noise. >> >> I would say that it would be nice to have Eclipse and Idea rules as >> similar as possible. The issue with that is that, for a while, the ORM >> people will have a lot of import changes, considering we can't make the >> Eclipse rules Idea like but we can do the opposite. >> >> If we don't want to bother the ORM team with that, we should split our >> rules between ORM and NoORM but it won't be very underestandable for the >> contributors (but it's not as if we had a lot of them and very few of them >> find our code styles without us mentioning them). >> >> -- >> Guillaume >> >> >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero >> wrote: >>> >>> Fundamentally no IDE will ever produce exactly the same code so you >>> need to learn control your primal lust for perfection and remember >>> it's not relevant. Have some decency ;) >>> >>> What does actually matter is that we don't keep chaging the order as >>> it introduces conflicts on backporting, it's very annoying and time >>> consuming in the long run. >>> >>> My solution is simple: I don't generally care, BUT commits containing >>> code reformats just for the sake of making one's favourite tool happy >>> need be rejected, especially to stop the bad habit from developing >>> further, or anyone trying to impose its own favourite tool of the day >>> as it was the only blessed way. >>> It's fine if a couple of import reorg "slip in" as part as meaningful >>> changes. >>> >>> The real problem is that applying a patch shouldn't conflict on import >>> statements; ideally there should be a conflict resolution strategy >>> able to understand it better (e.g. teach Java to git tools..) >>> >>> If you want to volunteer making the styles a bit more similar, I >>> typically prefer static imports last. >>> >>> -1 for CheckStyle rules unless you can figure out a way to exclude >>> existing code from failing: we're not going to reformat half the code >>> base to satisfy aesthetics. >>> >>> Perhaps we could have separate sets of rules, some stricter to be >>> applied on new modules; their impact would be limited but even having >>> one module with strict rules would encourage people to reconfigure >>> their IDE in "the right way". This would ensure all new code will be >>> consistent with the rules. >>> >>> Sergey sent a related PR but I'm not sure what to think of it as it >>> changes
Re: [hibernate-dev] [SEARCH] Code style - imports
On Tue, Sep 12, 2017 at 11:45 AM, Sanne Grinovero wrote: > Yes I'm "ok" with that. But wouldn't it be even better to leave this > level of detail undefined? > > At least it would allow me to make new code having them on the bottom > as I like them more, and you'd save some itme :) > The issue is not you writing new code, it's us updating it and reorganizing the import with the Eclipse rules. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [SEARCH] Code style - imports
On 12 September 2017 at 10:49, Yoann Rodiere wrote: > Well, if you don't mind me sending PRs with those imports in a different > order next time I change the file (because I don't spend time on organizing > imports manually, I just use CTRL+SHIFT+O), then yes, we can leave that > undefined. That works for me too. Just please avoid compulsive CTRL+SHIFT+O'ing around when there's no significant change ;) > > Yoann Rodière > Hibernate NoORM Team > yo...@hibernate.org > > On 12 September 2017 at 11:45, Sanne Grinovero wrote: >> >> On 12 September 2017 at 10:42, Yoann Rodiere wrote: >> >> Fundamentally no IDE will ever produce exactly the same code so you >> >> need to learn control your primal lust for perfection and remember >> >> it's not relevant. Have some decency ;) >> > >> > >> > Sorry if that seemed "indecent", but I did mention that I could live >> > with >> > the inconsistencies, and that what matters is their effect on our git >> > workflow :) >> > >> >> If you want to volunteer making the styles a bit more similar, I >> >> typically prefer static imports last. >> > >> > >> > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try >> > to >> > align the rest of the rules, though. >> > >> >> Sergey sent a related PR but I'm not sure what to think of it as it >> >> changes several things: >> >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 >> > >> > >> > Yes, it does more than what it advertises, and even the original idea >> > (putting static imports to the top) is not a good idea: ORM already has >> > static imports at the bottom in almost every file, so this change would >> > lead >> > to many more changes than necessary in commits for the ORM project for >> > some >> > time. >> > >> >> I would say that it would be nice to have Eclipse and Idea rules as >> >> similar as possible. The issue with that is that, for a while, the ORM >> >> people will have a lot of import changes, considering we can't make the >> >> Eclipse rules Idea like but we can do the opposite. >> > >> > >> > I doubt they'll ever agree with this solution. And I can't blame them. >> > >> >> If we don't want to bother the ORM team with that, we should split our >> >> rules between ORM and NoORM but it won't be very underestandable for >> >> the >> >> contributors (but it's not as if we had a lot of them and very few of >> >> them >> >> find our code styles without us mentioning them). >> > >> > >> > Seems to be the least disruptive solution. It's not ideal, but it should >> > improve the situation slightly and it wouldn't lead to more changes than >> > necessary in the future git commits. >> > @Sanne this means the imports will stay at the top, though. Ok with >> > that? >> >> Yes I'm "ok" with that. But wouldn't it be even better to leave this >> level of detail undefined? >> >> At least it would allow me to make new code having them on the bottom >> as I like them more, and you'd save some itme :) >> >> > >> > I'll try to see if I can add non-disruptive checkstyle rules too, if I >> > have >> > some time. >> > >> > Yoann Rodière >> > Hibernate NoORM Team >> > yo...@hibernate.org >> > >> > On 12 September 2017 at 11:31, Guillaume Smet >> > wrote: >> >> >> >> Hi, >> >> >> >> Yes, I had a hard time reverting the import changes in my recent >> >> patches >> >> for ORM. I was changing only a few lines per file and had a lot of >> >> import >> >> noise. >> >> >> >> I would say that it would be nice to have Eclipse and Idea rules as >> >> similar as possible. The issue with that is that, for a while, the ORM >> >> people will have a lot of import changes, considering we can't make the >> >> Eclipse rules Idea like but we can do the opposite. >> >> >> >> If we don't want to bother the ORM team with that, we should split our >> >> rules between ORM and NoORM but it won't be very underestandable for >> >> the >> >> contributors (but it's not as if we had a lot of them and very few of >> >> them >> >> find our code styles without us mentioning them). >> >> >> >> -- >> >> Guillaume >> >> >> >> >> >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero >> >> wrote: >> >>> >> >>> Fundamentally no IDE will ever produce exactly the same code so you >> >>> need to learn control your primal lust for perfection and remember >> >>> it's not relevant. Have some decency ;) >> >>> >> >>> What does actually matter is that we don't keep chaging the order as >> >>> it introduces conflicts on backporting, it's very annoying and time >> >>> consuming in the long run. >> >>> >> >>> My solution is simple: I don't generally care, BUT commits containing >> >>> code reformats just for the sake of making one's favourite tool happy >> >>> need be rejected, especially to stop the bad habit from developing >> >>> further, or anyone trying to impose its own favourite tool of the day >> >>> as it was the only blessed way. >> >>> It's fine if a couple of import reorg "slip in" as part as meaningful >> >>> changes. >> >>> >> >>> The r
Re: [hibernate-dev] [SEARCH] Code style - imports
Well, if you don't mind me sending PRs with those imports in a different order next time I change the file (because I don't spend time on organizing imports manually, I just use CTRL+SHIFT+O), then yes, we can leave that undefined. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On 12 September 2017 at 11:45, Sanne Grinovero wrote: > On 12 September 2017 at 10:42, Yoann Rodiere wrote: > >> Fundamentally no IDE will ever produce exactly the same code so you > >> need to learn control your primal lust for perfection and remember > >> it's not relevant. Have some decency ;) > > > > > > Sorry if that seemed "indecent", but I did mention that I could live with > > the inconsistencies, and that what matters is their effect on our git > > workflow :) > > > >> If you want to volunteer making the styles a bit more similar, I > >> typically prefer static imports last. > > > > > > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try > to > > align the rest of the rules, though. > > > >> Sergey sent a related PR but I'm not sure what to think of it as it > >> changes several things: > >> - https://github.com/hibernate/hibernate-ide-codestyles/pull/3 > > > > > > Yes, it does more than what it advertises, and even the original idea > > (putting static imports to the top) is not a good idea: ORM already has > > static imports at the bottom in almost every file, so this change would > lead > > to many more changes than necessary in commits for the ORM project for > some > > time. > > > >> I would say that it would be nice to have Eclipse and Idea rules as > >> similar as possible. The issue with that is that, for a while, the ORM > >> people will have a lot of import changes, considering we can't make the > >> Eclipse rules Idea like but we can do the opposite. > > > > > > I doubt they'll ever agree with this solution. And I can't blame them. > > > >> If we don't want to bother the ORM team with that, we should split our > >> rules between ORM and NoORM but it won't be very underestandable for the > >> contributors (but it's not as if we had a lot of them and very few of > them > >> find our code styles without us mentioning them). > > > > > > Seems to be the least disruptive solution. It's not ideal, but it should > > improve the situation slightly and it wouldn't lead to more changes than > > necessary in the future git commits. > > @Sanne this means the imports will stay at the top, though. Ok with that? > > Yes I'm "ok" with that. But wouldn't it be even better to leave this > level of detail undefined? > > At least it would allow me to make new code having them on the bottom > as I like them more, and you'd save some itme :) > > > > > I'll try to see if I can add non-disruptive checkstyle rules too, if I > have > > some time. > > > > Yoann Rodière > > Hibernate NoORM Team > > yo...@hibernate.org > > > > On 12 September 2017 at 11:31, Guillaume Smet > > wrote: > >> > >> Hi, > >> > >> Yes, I had a hard time reverting the import changes in my recent patches > >> for ORM. I was changing only a few lines per file and had a lot of > import > >> noise. > >> > >> I would say that it would be nice to have Eclipse and Idea rules as > >> similar as possible. The issue with that is that, for a while, the ORM > >> people will have a lot of import changes, considering we can't make the > >> Eclipse rules Idea like but we can do the opposite. > >> > >> If we don't want to bother the ORM team with that, we should split our > >> rules between ORM and NoORM but it won't be very underestandable for the > >> contributors (but it's not as if we had a lot of them and very few of > them > >> find our code styles without us mentioning them). > >> > >> -- > >> Guillaume > >> > >> > >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero > >> wrote: > >>> > >>> Fundamentally no IDE will ever produce exactly the same code so you > >>> need to learn control your primal lust for perfection and remember > >>> it's not relevant. Have some decency ;) > >>> > >>> What does actually matter is that we don't keep chaging the order as > >>> it introduces conflicts on backporting, it's very annoying and time > >>> consuming in the long run. > >>> > >>> My solution is simple: I don't generally care, BUT commits containing > >>> code reformats just for the sake of making one's favourite tool happy > >>> need be rejected, especially to stop the bad habit from developing > >>> further, or anyone trying to impose its own favourite tool of the day > >>> as it was the only blessed way. > >>> It's fine if a couple of import reorg "slip in" as part as meaningful > >>> changes. > >>> > >>> The real problem is that applying a patch shouldn't conflict on import > >>> statements; ideally there should be a conflict resolution strategy > >>> able to understand it better (e.g. teach Java to git tools..) > >>> > >>> If you want to volunteer making the styles a bit more similar, I > >>> typically prefer static imports last. > >>> > >>> -1 fo
Re: [hibernate-dev] [Search and more] What is new in a give release
>
> - Releases speaks less than downloads, Where do I download Hibernate X
> is a question we want addressed from the top level menus
>
Always amazed that there's still people out there actually downloading JARs
manually. But yes, we shouldn't forget about them.
My problem with "downloads" is that, while it conveys the correct meaning
for the minority (I hope) of users not using Maven/Gradle, it's really not
appropriate as an entry point to pages giving information about
series/releases.
Let's put it that way:
- To a user looking for info about a particular release (maven GAV,
changelog, ...) , a "download" entry isn't even remotely relevant
- To a user looking to download packages, a "releases" entry does seem a
bit relevant
But if you really want a "download" entry in the menu... would it be okay
if it just redirected to the "releases" page? I'll do that for now.
- if you do downloads -> releases, you need to also write some redirect
> rules not to break URLs
>
I already did. Redirects don't seem to work locally for some reason,
though. They work on staging.
> - I don't like the term maintained much, I think latest like you
> proposed makes it more neutral. You could even just name them Series
>
Steve found "latest releases" "confusing" (if I understood correctly). I
changed it to "Series" as you suggested.
> - The migration guide should probably be referenced from each individual
> series page.
>
Done.
> - the matrix does not scale very well to that many versions.
>
Could you be more specific? Is it that you're having trouble finding out
which cell relates to which HSearch version, or which cell relates to which
dependency, or about the size of columns not being the same, or... ? I'd
rather know exactly what's wrong before trying to mess with the CSS,
because solutions to each of these problems will probably require to use
more horizontal space, and as you can see we don't have that much available.
> - in the dedicated series page, "Reference" is confusing, I'd probably
> replace it with documentation or main documentation
Done.
Since there seems to be a general agreement that it's not worse than it
used to be, I'll send a PR soon. We can continue the discussion there.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On 11 September 2017 at 15:54, Emmanuel Bernard
wrote:
> Hey Yoann and all,
>
> Thanks Yoann for stepping up. This is definitely much better.
> Here are non ordered comments:
>
> - Releases speaks less than downloads, Where do I download Hibernate X
> is a question we want addressed from the top level menus
> - if you do downloads -> releases, you need to also write some redirect
> rules not to break URLs
> - I don't like the term maintained much, I think latest like you
> proposed makes it more neutral. You could even just name them Series
> - The migration guide should probably be referenced from each individual
> series page.
> - the matrix does not scale very well to that many versions.
> - in the dedicated series page, "Reference" is confusing, I'd probably
> replace it with documentation or main documentation
>
> Emmanuel
>
> On Fri 17-09-08 14:53, Yoann Rodiere wrote:
>
>> Hey,
>>
>> I pushed an update to staging. I only converted the "Search" part for now.
>> What changes:
>>
>> - The _data folder structured changed a bit, so that we can introduces a
>> YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a
>> summary
>> of this series and a list of integration constraints (ORM > 5.2, etc.)
>> - The "Downloads" page is renamed to "Releases", since, well, it's about
>> more than just downloads. See
>> http://staging.hibernate.org/search/releases/
>> - The "Releases" page now includes a "Compatibilty matrix" section based
>> on the new data I mentioned above
>> - The "Releases" page now includes links to one page for each series
>> ("More on the 5.8 series")
>> - There is now one page for each series (see
>> http://staging.hibernate.org/search/releases/series/5.8/). This page
>> includes:
>> - A short (one-line) summary of this series
>> - A reminder of the integration constraints for this series
>> - A section about the main changes in this release. I only wrote
>> something for the 5.8 series for now, and I basically
>> copy/pasted sections
>> from various blog posts.
>> - A list of all releases in this series.
>>
>> What I didn't do, but could make sense:
>>
>> - add a sub-menu element under "Releases" for each series
>> - link to the documentation for each of the latest releases from the
>> "Releases" page
>> - link to the latest documentation and to the migration guides from each
>> series' page
>>
>> What do you all think? Emmanuel, would this address your concerns? Steve,
>> would this be a good fit for ORM?
>>
>> Yoann Rodière
>> Hibernate NoORM Team
>> yo...@hibernate.org
>>
>> On 6 September 2017 at 17:16, Steve Ebersole wrote:
>>
>> This is som
[hibernate-dev] NoORM IRC meeting minutes
Hi, Here are the minutes of the NoORM IRC meeting: 16:33 < jbott> Meeting ended Tue Sep 12 14:33:25 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:33 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-12-13.16.html 16:33 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-12-13.16.txt 16:33 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-09-12-13.16.log.html Have a nice day! -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] How is LogicalConnectionImplementor#makeShareableCopy intended to be used?
LogicalConnectionImplementor#makeShareableCopy [1] doesn't seem to be used by anything. The implemented method in LogicalConnectionManagedImpl returns null. [2] Should this method be deprecated? I'm asking because I created a PR [3] that allows passing JdbcObserver to ResourceRegistryStandardImpl so that any existing batch can be cleaned up before releasing JDBC resources. In my PR, the LogicalConnectionProvidedImpl#makeShareableCopy results in a LogicalConnectionProvidedImpl with a ResourceRegistryStandardImpl that has a null JdbcObserver. It didn't make sense to me that the original and shareable ResourceRegistryStandardImpl should both have the same JdbcObserver, but I'm really not sure about this. If LogicalConnectionImplementor#makeShareableCopy really is not used and should be deprecated, I won't worry about this. I'd like to get my PR merged for 5.2.11 tomorrow, so a quick response would be greatly appreciated. If I don't hear back, I'll push it to 5.2.12. Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/spi/LogicalConnectionImplementor.java#L61-L66 [2] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/resource/jdbc/internal/LogicalConnectionManagedImpl.java#L217-L223 [3] https://github.com/hibernate/hibernate-orm/pull/2004 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
