August 2022 - hibernate-issues - Jboss List Archives

[JIRA] (HSEARCH-2366) Add an Elasticsearch mapping export tool

by Yoann Rodière (JIRA)

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4675) Use .and()/.or() rather than .bool() where possible in documentation and tests

by Yoann Rodière (JIRA)

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4591) Allow object projections on single-valued, flattened object fields with the Lucene backend

by Yoann Rodière (JIRA)

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4675) Use .and()/.or() rather than .bool() where possible in documentation and tests

by Yoann Rodière (JIRA)

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4616) Rename automatic indexing to something more explicit

by Yoann Rodière (JIRA)

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4676) Use .and() syntax by default with .where(BiFunction) and .nested() predicate?

by Yoann Rodière (JIRA)

2 years, 4 months

1
0
0 / 0

[JIRA] (HHH-15459) OPTIMISTIC_FORCE_INCREMENT and PESSIMISTIC_FORCE_INCREMENT update version more then once

by Fabian Köntopp (JIRA)

Fabian Köntopp ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6278292... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYzFhY2FjYTY2... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-15459?atlOrigin=eyJpIjoiYzFhY2... ) HHH-15459 ( https://hibernate.atlassian.net/browse/HHH-15459?atlOrigin=eyJpIjoiYzFhY2... ) OPTIMISTIC_FORCE_INCREMENT and PESSIMISTIC_FORCE_INCREMENT update version more then once ( https://hibernate.atlassian.net/browse/HHH-15459?atlOrigin=eyJpIjoiYzFhY2... ) Issue Type: Bug Affects Versions: 5.6.10 Assignee: Unassigned Components: hibernate-core Created: 22/Aug/2022 05:05 AM Priority: Major Reporter: Fabian Köntopp ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6278292... ) When using this ( https://vladmihalcea.com/how-to-increment-the-parent-entity-version-whene... ) proposal from @Vlad Mihalcea, updating multiple fields from multiple childs in one transaction increases the version number not by one but by the number of changed child entities. My understanding is, that the version number should be updated only once for one transaction even if the OPTIMISTIC_FORCE_INCREMENT or PESSIMISTIC_FORCE_INCREMENT lock modes are used multiple times in it. ( https://hibernate.atlassian.net/browse/HHH-15459#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15459#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100205- sha1:59a7aeb )

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4677) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiY2MxMzdj... ) / Task ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiY2M... ) HSEARCH-4677 ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiY2M... ) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiY2M... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Follows up on [https://hibernate.atlassian.net/browse/HSEARCH-4601|https://hibernate.atl...]. See the discussion [starting here|https://github.com/hibernate/hibernate-search/pull/3152#issuecomment...]: {quote}> And now, by reading the examples with lambdas, i.e. when the operator instantiation and the add operations are distant from one another, I'm wondering if such syntax isn't requiring an excessive cognitive load for casual readers to figure out what kind of operation this add is performing. I'd say the cognitive load would be reduced if the methods were to be more explicitly named {{and}} and {{or}}. That means getting back to the situation before you de-duplicated all the interfaces, then :) That might be clearer for long chains of {{.add()}}, but I find it strange to use {{and}}/{{or}} for the very first clause, and that would also feel very redundant, e.g. {{f.and().and( e1 ).and( e2 )}}. It would also prevent developers from writing "generic" functions that simply add multiple clauses to a boolean predicate, without knowing whether it's an {{and}} or an {{or}}; not a big deal, but worth mentioning. {quote} {quote} > In addition to making code more self-explanatory, having specific "{{add}}" methods would be less error-prone when different predicates are used in different {{with(...)}} constructs, as in "Example 228. Easily adding clauses dynamically using with(…) and the lambda syntax". That wouldn't make things less error-prone for {{and}}/{{and}} nesting though, e.g. {{f.and().and( ... ).and( f.nested().and( ... ).and( ... ) )}}. > For the forthcoming {{not}} predicate (HSEARCH-4645), renaming {{add}} to something like {{andNot}} may also be more explicit. To me that's one more reason to _not_ introduce and {{add}} syntax for {{not}}: make that predicate accept a _single_ inner clause and leave it at that. People can still nest an {{and}} predicate if they want to, and we can always try to "flatten" expressions under the hood with some tricks (which we'll probably need for the {{not()}} predicate anyway).{quote} ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100205- sha1:59a7aeb )

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4677) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiOWMwOGM3... ) / Task ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiOWM... ) HSEARCH-4677 ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiOWM... ) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiOWM... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Follows up on [https://hibernate.atlassian.net/browse/HSEARCH-4601|https://hibernate.atl...]. See the discussion [starting here|https://github.com/hibernate/hibernate-search/pull/3152#issuecomment...]: {quote}> And now, by reading the examples with lambdas, i.e. when the operator instantiation and the add operations are distant from one another, I'm wondering if such syntax isn't requiring an excessive cognitive load for casual readers to figure out what kind of operation this add is performing. I'd say the cognitive load would be reduced if the methods were to be more explicitly named {{and}} and {{or}}. That means getting back to the situation before you de-duplicated all the interfaces, then :) That might be clearer for long chains of {{.add()}}, but I find it strange to use {{and}}/{{or}} for the very first clause, and that would also feel very redundant, e.g. {{f.and().and( e1 ).and( e2 )}}. It would also prevent developers from writing "generic" functions that simply add multiple clauses to a boolean predicate, without knowing whether it's an {{and}} or an {{or}}; not a big deal, but worth mentioning. {quote} Another solution {quote}> In addition to making code more self-explanatory, having specific "{{add}}" methods would be to alter conventions less error-prone when different predicates are used in different {{with(...)}} constructs , i as in "Example 228. e Easily adding clauses dynamically using with(…) and the lambda syntax". to use That wouldn't make things less error-prone for {{and}}/{{ or and }} as the name of the lambda parameter ( nesting though, e.g. {{f.and(). with( and -> (... ) }}). That would reduce the cognitive load when using {{with}}, at least, but obviously not when using the fluent syntax {{ and( f. and nested (). add and (...). add and (...) ) }}. That being said, I'd argue > For the fluent syntax is more suited forthcoming {{not}} predicate (HSEARCH-4645), renaming {{add}} to short chains; I’d use something like {{.with andNot }} for longer chains spanning many lines of code may also be more explicit. For now, I To me that ' ll use s one more reason to _not_ introduce and {{ and add }} / syntax for {{ or not }} as the name of the lambda parameter in tests : make that predicate accept a _single_ inner clause and examples leave it at that. People can still nest an {{and}} predicate if they want to , and I'll open another ticket we can always try to re-evaluate "flatten" expressions under the problem before hood with some tricks (which we release 6 'll probably need for the {{not()}} predicate anyway). 2.0.Final. {quote} ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100205- sha1:59a7aeb )

2 years, 4 months

1
0
0 / 0

[JIRA] (HSEARCH-4677) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiMDdhZjY1... ) / Task ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiMDd... ) HSEARCH-4677 ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiMDd... ) Rename .add(...) to .and(...)/.or(...) in "simple" boolean predicates ( https://hibernate.atlassian.net/browse/HSEARCH-4677?atlOrigin=eyJpIjoiMDd... ) Issue Type: Task Assignee: Unassigned Components: engine Created: 22/Aug/2022 04:48 AM Fix Versions: 6.2-backlog Priority: Major Reporter: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Follows up on https://hibernate.atlassian.net/browse/HSEARCH-4601 ( https://hibernate.atlassian.net/browse/HSEARCH-4601 ). See the discussion starting here ( https://github.com/hibernate/hibernate-search/pull/3152#issuecomment-1220... ) : > > > > > And now, by reading the examples with lambdas, i.e. when the operator > instantiation and the add operations are distant from one another, I'm > wondering if such syntax isn't requiring an excessive cognitive load for > casual readers to figure out what kind of operation this add is > performing. I'd say the cognitive load would be reduced if the methods > were to be more explicitly named and and or. > > > > That means getting back to the situation before you de-duplicated all the > interfaces, then That might be clearer for long chains of.add() , but I > find it strange to use and / or for the very first clause, and that would > also feel very redundant, e.g. f.and().and( e1 ).and( e2 ). It would also > prevent developers from writing "generic" functions that simply add > multiple clauses to a boolean predicate, without knowing whether it's an and > or an or ; not a big deal, but worth mentioning. > > > > Another solution would be to alter conventions, i.e. to use and / or as the > name of the lambda parameter (e.g. f.and().with( and -> ... ) ). That would > reduce the cognitive load when using with , at least, but obviously not > when using the fluent syntax f.and().add(...).add(...). That being said, > I'd argue the fluent syntax is more suited to short chains; I’d use.with for > longer chains spanning many lines of code. > > > > For now, I'll use and / or as the name of the lambda parameter in tests and > examples, and I'll open another ticket to re-evaluate the problem before > we release 6.2.0.Final. > > ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4677#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100205- sha1:59a7aeb )

2 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2022