[hibernate-dev] Re: Cannot resolve method 'type'

Hi, let's move that discussion to Zulip, since you posted your question there as well: https://hibernate.zulipchat.com/#narrow/stream/132096-hibernate-user/topic/Cannot.20resolve.20method.20'type' Regards, Christian Am 19.08.2023 um 23:38 schrieb Peter Penzov: Hello, I want to migrate to

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

Looks great, thanks for writing that up! Am 02.06.2022 um 18:52 schrieb Steve Ebersole: Let me know what y'all think - https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team On Thu, Jun 2, 2022 at 7:37 AM Steve Ebersole wrote: I think we generally agree and understand each

[hibernate-dev] Re: ORM 6 + staged Jakarta Persistence 3.1 SPEC API jar...

Just a small heads up, if we ignore the tests we challenged and fix the new tests (new for JPA 3.1) for which I provided PRs, we pass the current TCK with RC2 with minimal changes[1]. I see that some more changes were pushed to the JPA API repository and I started working on implementations

[hibernate-dev] Hibernate ORM 5.6.4.Final has been released

Hello all, we've released Hibernate ORM version 5.6.4.Final ! For details: https://in.relation.to/2022/01/19/hibernate-orm-564/ Thanks all! Christian ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to

[hibernate-dev] Hibernate ORM 5.5.0.Final has been released

Hello all, we've released Hibernate ORM version 5.5.0.Final ! For details: https://in.relation.to/2021/06/02/hibernate-orm-550-final-release/ Thanks all! Christian ___

[hibernate-dev] Hibernate ORM 5.5.0.Alpha1 has been released

Hello all, we've released Hibernate ORM version 5.5.0.Alpha1 ! For details: https://in.relation.to/2021/04/30/hibernate-orm-550-alpha1-release/ Thanks all! Christian ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe

[hibernate-dev] Re: Dialect.supportsValuesList() ignored for InsertUpdateTests.testInsertValues

Hey Mark, please consider the value that `Dialect.supportsValuesList()` returns as irrelevant. It doesn't return the correct value for all databases as you figured. Apart from that, we are trying to get rid of such functions in Dialect and integrate this into the SqlAstTranslator as much as

[hibernate-dev] Re: Dialect.supportsValuesList() ignored for InsertUpdateTests.testInsertValues

2021, 10:59: > Ah, now I understand. Unfortunately that isn't an option in Firebird, > CTEs only support select. > > Mark > > On 08-03-2021 10:19, Christian Beikov wrote: > > Take a look into > > org.hibernate.query.sqm.mutation.internal.cte.CteStrategy which use

[hibernate-dev] Re: Dialect.supportsValuesList() ignored for InsertUpdateTests.testInsertValues

09:40, Christian Beikov wrote: thanks for the report. As you figured, this is currently not handled. The method was introduced for a CTE mutation strategy that I rewrote and the method currently has no real use. I agree though that it makes sense to make use of it for this purpose. I don't

[hibernate-dev] Re: Dialect.supportsValuesList() ignored for InsertUpdateTests.testInsertValues

Hi Mark, thanks for the report. As you figured, this is currently not handled. The method was introduced for a CTE mutation strategy that I rewrote and the method currently has no real use. I agree though that it makes sense to make use of it for this purpose. I don't know if it makes sense

[hibernate-dev] Re: Query generated for insert ... select

That's a bug. It should be a root. I'll fix that on Monday. Mark Rotteveel schrieb am Sa., 6. März 2021, 11:01: > For an INSERT ... SELECT, Hibernate (in wip/6.0) will generate a SQL > statement with parentheses around the select statement. > > This happens in

[hibernate-dev] Re: FetchMode.SELECT

I agree that this should be supported. Specifying a fetch mode should IMO not change the fetch type to LAZY or EAGER. Am 06.01.2021 um 04:50 schrieb Gail Badner: Should it be possible to force an eager association to be loaded by a separate query using @Fetch(FetchMode.SELECT)? I thought that

[hibernate-dev] Re: Regarding lazy initialization of ArrayList

Hey Nathan, I like the idea in general and but you have to be careful with changing this as I assume this was done to save memory by creating the list, only when at least one element would be added to the list. I guess if we always initialize the list, we'd have to do something like the

Re: [hibernate-dev] Bad boot performance since 5.4 switched to ByteBuddy

ot much better results by caching > the ByteBuddy transformations. In particular the calls to the > ByteBuddy DSL are quite expensive in terms of allocations because they > are creating a ton of objects. > > Once we have some profiling results, we can talk. > > -- > Guillaum

[hibernate-dev] Bad boot performance since 5.4 switched to ByteBuddy

I'm moving this discussion from Zulip to the mailing list as Rafael does not seem to be on Zulip. Here a little context: > Does anyone know if there is a known performance issue with Bytebuddy during boot in 5.4? I noticed that 5.4 takes about 25%, sometimes up to 30% percent longer to boot,

Re: [hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?

Hey, I'm not sure it is a good idea to do this for Hibernate ORM 6 already as that would probably hinder adoption. Some projects just didn't update to Java 9+ yet because using the newer versions would have no real benefit. We can use the Multi-Release JAR feature to make use of JDK features

Re: [hibernate-dev] Can a transient attribute be overridden to be persistent in a subclass?

I agree, this should work. Do you have a JIRA ticket describing what the problem is? Am 09.07.2020 um 02:42 schrieb Gail Badner: > I *think* the following is valid, but I need confirmation. This mapping > does seem to work for Hibernate. > > A transient attribute, Employee#title, gets overridden

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

10.03.2020 um 12:56 schrieb Sanne Grinovero: > Hi Christian, > > On Tue, 10 Mar 2020 at 11:33, Christian Beikov > wrote: >> Hey, >> >> do you think it is feasible to create a separate artifact that is a >> bytecode rewriting of the main artifact, replacing

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

Hey, do you think it is feasible to create a separate artifact that is a bytecode rewriting of the main artifact, replacing javax.persistence by jakarta.persistence. This should be no big deal as e.g. the Maven Shade Plugin does that as well. We would only need to accept additonal poperties

Re: [hibernate-dev] 6.0 - HQL literals

Ok, just wanted to make sure I didn't miss anything and understand the reasoning for your preference :) Am 09.01.2020 um 13:06 schrieb Steve Ebersole: > Well, again, this is configurable.  If you don't want to use it, don't ;) > > On Thu, Jan 9, 2020 at 1:28 AM Christi

Re: [hibernate-dev] 6.0 - HQL literals

Am 08.01.2020 um 20:21 schrieb Steve Ebersole: > On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov > mailto:christian.bei...@gmail.com>> wrote: > > > This is about JPA Criteria whereas I was referring to how a > literal in > HQL ends up in the SQL. I agree th

Re: [hibernate-dev] 6.0 - HQL literals

Am 08.01.2020 um 14:47 schrieb Steve Ebersole: > On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov > mailto:christian.bei...@gmail.com>> wrote: > > Am 08.01.2020 um 13:50 schrieb Steve Ebersole: > > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov > > mai

Re: [hibernate-dev] 6.0 - HQL literals

Am 08.01.2020 um 13:50 schrieb Steve Ebersole: > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov > mailto:christian.bei...@gmail.com>> wrote: > > If a user enters a HQL literal, that user wants the literal to be > rendered like that if possible(which should always be

Re: [hibernate-dev] 6.0 - HQL literals

literals would be interpreted > correctly in such scenarios. > > > Yoann Rodière > Hibernate Team > yo...@hibernate.org <mailto:yo...@hibernate.org> > > > On Wed, 8 Jan 2020 at 12:41, Christian Beikov > mailto:christian.bei...@gmail.com>> wrote: >

Re: [hibernate-dev] 6.0 - HQL literals

Can't we just render a literal in the DBMS proprietary way as literal again but with respective TZ information to avoid TZ issues in the JDBC driver? If we use an instant literal we use the UTC TZ in a SQL literal or function to render that. Yoann Rodiere schrieb am Mi., 8. Jän. 2020, 11:22: >

Re: [hibernate-dev] HHH-11147 - bytecode based "proxies"

+1 for 6 Am 13.05.2019 um 15:25 schrieb Steve Ebersole: > Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which > essentially allows bytecode enhancement to behave like the more traditional > proxy feature (create a reference based solely on the entity id). > > We are

Re: [hibernate-dev] Chat migration - D minus 115 until the death of HipChat

I'm fine with it. Am 06.12.2018 um 08:52 schrieb Yoann Rodiere: > The WildFly team is moving from Slack to Zulip, because Zulip seems to be > the only solution that is free, provides unlimited history, and allows > unlimited users even in private rooms (for OSS projects, at least). Gitter > has

Re: [hibernate-dev] 6.0 Alpha1 prep

Am 05.12.2018 um 15:20 schrieb Steve Ebersole: > Another one.. > > `hibernate-orm-modules` defines a `hibernate-envers` module (in the WF > modules sense). Since envers is now part of `hibernate-core` should we > remove that module or have it just act as an alias for the main orm module? IMO a

Re: [hibernate-dev] 6.0 Alpha1 prep

Am 05.12.2018 um 14:42 schrieb Steve Ebersole: > As I am preparing the Alpha1 release a few topics of discussion have come > up... > > Previously (last year's f2f) we had decided to unify the artifact naming > conventions; specifically for ORM this meant renaming the groupId from > `org.hibernate`

Re: [hibernate-dev] Reducing the memory usage of HQLQueryPlan

, but maybe there are other reasons to keep it around? Wdyt? Mit freundlichen Grüßen, *Christian Beikov* Am 09.08.2018 um 16:57 schrieb Steve Ebersole: > In 6.0 HQLQueryPlan is replaced by AggregatedSelectQueryPlanImp

Re: [hibernate-dev] Stride

Slack does require more memory than other solutions, running on 200 MB here for 3 Organizations, but it is a really nice tool. So my preference is Slack. Mit freundlichen Grüßen, *Christian Beikov* Am 27.07.2018 um 09:19

Re: [hibernate-dev] Multiple ResultSets from JDBC execution

+1 from me as well on that. Mit freundlichen Grüßen, *Christian Beikov* Am 25.05.2018 um 17:24 schrieb Scott Marlow: > On Fri, May 25, 2018 at 8:59 AM, Steve Ebersole wrote: > >> Great that was actually my tho

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

why I was saying I'm not sure about it. Maybe someone else has an idea if using ManagedBeanRegistry might make sense? Mit freundlichen Grüßen, *Christian Beikov* Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea: > Hi, > >

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

It looks ok to me although I'm not sure if it wouldn't be more appropriate to instantiate the contributor via ManagedBeanRegistry. Mit freundlichen Grüßen, *Christian Beikov* Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea

Re: [hibernate-dev] Depending on JAXB / JDK11 compatibility

, as users could simply exclude the dependency if they like without messing up other transitive dependencies. Mit freundlichen Grüßen, *Christian Beikov* Am 02.05.2018 um 23:48 schrieb Guillaume Smet: > On Wed, May 2, 2018 at

Re: [hibernate-dev] Depending on JAXB / JDK11 compatibility

.bind" module. People will have to adapt to this and add their own JAXB implementation, just like they now use Hibernate as JPA implementation. Mit freundlichen Grüßen, *Christian Beikov* Am 02.05.2018 um 23:24 sch

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

Am 25.04.2018 um 00:46 schrieb Steve Ebersole: > > > On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > That's a possibility indeed, but there will most likely always be > s

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

the function. Mit freundlichen Grüßen, -------- *Christian Beikov* Am 25.04.2018 um 00:25 schrieb Steve Ebersole: > What I was proposing instead was to treat extract and hopefully > datediff as first-class citizens: > > cb.e

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

separate functions which would ultimately look a lot cleaner. Mit freundlichen Grüßen, *Christian Beikov* Am 25.04.2018 um 00:11 schrieb Steve Ebersole: > Yep, it was clear > > On Tue, Apr 24, 2018 at 4:57 P

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

w it could look. Mit freundlichen Grüßen, *Christian Beikov* Am 24.04.2018 um 16:33 schrieb Steve Ebersole: > JPA is technically under the old JCP still AFAIK. So for now the > process would be the same it has always bee

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

Foundation work, or is it not yet defined? I'd be curious what it takes for an idea or a feature to be considered. Mit freundlichen Grüßen, *Christian Beikov* Am 24.04.2018 um 16:12 schrieb Steve Ebersole: > When you

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

en further and standardize the definition of functions, but I guess that's not going to happen, so this seems to be a good compromise/first step. Mit freundlichen Grüßen, *Christian Beikov* Am 24.04.2018 um 15:21 schrieb Gail Bad

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

t it. Mit freundlichen Grüßen, ---- *Christian Beikov* Am 24.04.2018 um 07:29 schrieb Gail Badner: > SQL Server defines a function: > > DATEDIFF ( datepart , startdate , enddate ) [1] > > (This method still needs to be added to S

Re: [hibernate-dev] Joins over type variable defined assocations NPE problems

confirmed that the fix works for him. Mit freundlichen Grüßen, *Christian Beikov* Am 13.03.2018 um 20:06 schrieb Steve Ebersole: > I think it is ok to disallow implicit downcasting in cases where the > downcast is non-dete

Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

Hey, I'm fine with reverting the patch as well, though I just fixed the issue Andrea found and am confident about the solution now. Mit freundlichen Grüßen, *Christian Beikov* Am 06.03.2018 um 11:57 schrieb Guillaume Smet

Re: [hibernate-dev] Null-Pointer Exception with 5.2.14

t;>> } >>> else { >>> commonPersistentClass = commonPersistentClass.getSuperclass(); >>> commonMappedSuperclass = null; >>> } >>>} >>> } >>> >>> As you can see the commonMappedSuperclass is not initialized and s

Re: [hibernate-dev] Null-Pointer Exception with 5.2.14

Hey, I saw the comment on the issue. Thanks for reporting. Could you maybe post the model that causes this? I'd need to create a reproducer to be able to analyze this further. Mit freundlichen Grüßen, *Christian Beikov

[hibernate-dev] Bulk delete behavior for collection tables

Don't know if that can be classified as breaking behavior. Or have two configuration options? Even then, would we enable collection table entry deletion by default? -- Mit freundlichen Grüßen, *Christian

Re: [hibernate-dev] New layout for the website

, *Christian Beikov* Am 26.09.2017 um 13:19 schrieb Guillaume Smet: > Hi, > > Following Yoann's work and based on it, I tried to work on a new layout for > the website. > > The idea was to make it more modern while not starting a full discussion > about the content. I think

Re: [hibernate-dev] Continue to add 5.2 deprecations for 6.0 work?

I think a deprecation with @Deprecated should be enough/is more appropriate for this. Mit freundlichen Grüßen, *Christian Beikov* Am 28.06.2017 um 16:45 schrieb Steve Ebersole: > A rose by any other name... I am f

Re: [hibernate-dev] HHH-11791

entation, this seems like a real deep cut that touches many places. Mit freundlichen Grüßen, -------- *Christian Beikov* Am 12.06.2017 um 23:47 schrieb Christian Bongiorno: > To work, yes. This would be an optional means of in

Re: [hibernate-dev] SQM and cast targets

but can optionally define in parenthesis the concrete DBMS type. Valid examples would be something like cast( x as String ), cast( x as String( varchar ) ), cast( x as String( varchar2( 5000 ) ) ) What do you think about that? Mit freundlichen Grüßen, ------

Re: [hibernate-dev] 6.0 - formalized standard functions

Answers inline... Am 31.05.2017 um 14:38 schrieb Steve Ebersole: > Thanks for reply Christian.. > > > On Wed, May 31, 2017 at 7:18 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > Looks good. OTOH I'd also li

Re: [hibernate-dev] SQM and cast targets

Yeah the example you gave would reflect what I was thinking about. How would you determine the expression type if the castTarget is just "passed-through" then? Mit freundlichen Grüßen, *Christian Beikov* Am 31.

Re: [hibernate-dev] 6.0 - formalized standard functions

argument and an empty string literal. IIRC this operation is kind of "context-sensitive" i.e. it will choose a more appropriate text type when a type can be inferred. Mit freundlichen Grüßen, -------- *Christian Beik

Re: [hibernate-dev] SQM and cast targets

for the pass-through case. Wdyt? Mit freundlichen Grüßen, -------- *Christian Beikov* Am 30.05.2017 um 18:00 schrieb Steve Ebersole: > How about this rule then? > > castTarget > // should allow either > // - named cast (IDENTIFIER) > //- JavaTypeDescrip

Re: [hibernate-dev] SQM and cast targets

an option to cast to CLOB, TEXT or whatever other datatype a DBMS offers. Mit freundlichen Grüßen, *Christian Beikov* Am 29.05.2017 um 16:17 schrieb Steve Ebersole: > Currently casting in HQL is under-defined a

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

rialized or annotate your existing entities with those "ignore" annotations and hope for the best. I don't see how hibernate could or should help in any of the two cases. Mit freundlichen Grüßen, ---- *Christian

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

I don't understand what you mean by "you put that logic in the conversion", could you elaborate? Mit freundlichen Grüßen, *Christian Beikov* Am 04.05.2017 um 16:32 schrieb Romain Manni-Bucau: > Few more point

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

hen Grüßen, *Christian Beikov* Am 04.05.2017 um 10:20 schrieb Emmanuel Bernard: > Following up a bit on my previous email. > > While a core integration might be best I think, if there are too much > reluctance, we can start with a dedicated hib

Re: [hibernate-dev] 6.0 - concept naming

Hehe too fast, I meant option 3. :D Mit freundlichen Grüßen, *Christian Beikov* Am 03.05.2017 um 16:01 schrieb Steve Ebersole: > To circle back to this... I mentioned possibly keeping a reference to > the forei

Re: [hibernate-dev] 6.0 - concept naming

Option 1 sounds good. Mit freundlichen Grüßen, *Christian Beikov* Am 03.05.2017 um 16:01 schrieb Steve Ebersole: > To circle back to this... I mentioned possibly keeping a reference to > the foreign-key defining th

Re: [hibernate-dev] WebSphereExtendedJtaPlatform (HHH-11606)

undlichen Grüßen, ---- *Christian Beikov* Am 03.05.2017 um 09:48 schrieb Gail Badner: > Currently, in master and 5.1, WebSphereExtendedJtaPlatform will not work > for any tasks that use a DdlTransactionIsolatorJtaImpl. > > The problem is that DdlTran

Re: [hibernate-dev] 6.0 - JPA metamodel code

No objections from my side. Can't imagine anyone uses the internals. Mit freundlichen Grüßen, *Christian Beikov* Am 28.04.2017 um 18:44 schrieb Steve Ebersole: > Currently Hibernate implements the JPA metamodel contra

Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

much, just wanted to say that I had the same issues over and over which is why I started that project. Mit freundlichen Grüßen, -------- *Christian Beikov* Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau: > Hi guys, > >

Re: [hibernate-dev] 6.0 - concept naming

tables in the EntityPersister. I guess that issue would be solved then? :) Mit freundlichen Grüßen, *Christian Beikov* Am 14.04.2017 um 18:24 schrieb Steve Ebersole: > Before I get deeper into this persister work I wan

Re: [hibernate-dev] 6.0 - id type

+1 for that. Stumbled over that once or twice in the past and wondered what the reasons were. Mit freundlichen Grüßen, *Christian Beikov* Am 27.03.2017 um 19:37 schrieb Steve Ebersole: > In all versions of Hibern

Re: [hibernate-dev] SQL Server lock hints misunderstanding

I'm not using SQL Server myself but this sounds reasonable. Mit freundlichen Grüßen, *Christian Beikov* Am 23.03.2017 um 11:53 schrieb Vlad Mihalcea: > --works > select TOP(?) abstractsk0_.id as id1_0_, abstra

Re: [hibernate-dev] HHH-10162 Inheritance and L2 cache

Hey Gail, comments inline.. Am 15.03.2017 um 23:21 schrieb Gail Badner: > Hi Christian, > > More comments below... > > On Fri, Mar 3, 2017 at 4:38 PM, Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > Tha

Re: [hibernate-dev] HHH-11396 - Timezone handling

for the fuss, this timezone handling really is hard :D Mit freundlichen Grüßen, *Christian Beikov* Am 15.03.2017 um 18:02 schrieb Steve Ebersole: > I'm not sure exactly where the fault lies (java.util versus java.sql), but > we

Re: [hibernate-dev] HHH-11396 - Timezone handling

, *Christian Beikov* Am 14.03.2017 um 10:39 schrieb Jordan Gigov: > What java.sql.Date does is wrong for many reasons (mostly because it > extends java.util.Date which is a horrible API), but I think Vlad laid > it out pretty

[hibernate-dev] HHH-11396 - Timezone handling

ifting the millisecond value back when constructing a LocalDate. What do you think should we do? Does anyone maybe know why java.sql.Date behaves that way? -- Mit freundlichen Grüßen, *Christian

Re: [hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

In that case I'd say let's do it if it makes sense :) Mit freundlichen Grüßen, *Christian Beikov* Am 10.03.2017 um 00:14 schrieb Steve Ebersole: > > That's basically exactly what @Incubating means - we are ex

Re: [hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

Is there a definition to what @Incubating means? I'd rather not make it an API until we played a little with it for new features. Mit freundlichen Grüßen, *Christian Beikov* Am 09.03.2017 um 17:35 schrieb Steve Ebersole

Re: [hibernate-dev] HHH-10162 Inheritance and L2 cache

hese improvements, I think we should apply the L2 cache fix and handle the rest later. What do you say? Mit freundlichen Grüßen, -------- *Christian Beikov* Am 04.03.2017 um 00:42 schrieb Gail Badner: > Hi Christian, > > I've

Re: [hibernate-dev] HHH-10162 Inheritance and L2 cache

I can, just wanted to hear some general opinions before creating the PR. Will do that tomorrow. Mit freundlichen Grüßen, *Christian Beikov* Am 02.03.2017 um 20:57 schrieb Gail Badner: > Hi Christian, > > You

[hibernate-dev] HHH-10162 Inheritance and L2 cache

ussion in the Dev room, but so far only Andrea, Vlad and Chris have commented this. Has anyone a different idea for implementing this? -- Mit freundlichen Grüßen, *Christian

Re: [hibernate-dev] DB2 cross joins

How about a different approach? Like passing the DB version somehow to the dialect so that it can decide for itself instead of having different subclasses. Am 16.02.2017 um 08:16 schrieb Gail Badner: > HHH-11487 can be fixed by using changing DB2Dialect#getCrossJoinSeparator > to return " cross

Re: [hibernate-dev] Hibernate ORM 6.0 groupId/artifactId

Sounds good to me. +1 Am 30.01.2017 um 17:31 schrieb Steve Ebersole: > Relatedly, I have been thinking whether we want to rename the ORM artifacts > as well since this is the best time if we wanted to do that. > > So we know we will change the groupId to `org.hibernate.orm`. > > I was thinking we

Re: [hibernate-dev] Extended KEY expression support

I created an issue for this feature: https://hibernate.atlassian.net/browse/HHH-11433 If we agree to render "domain joins" that involve multiple tables with the ANSI SQL parenthesis join syntax, we can actually even "ignore" the join types for key and value tables. That would make things like

Re: [hibernate-dev] Extended KEY expression support

Fwiw EclipseLink supports both syntaxes "JOIN KEY(m) k" and also "JOIN KEY(m).association". Am 27.01.2017 um 20:25 schrieb Christian Beikov: > I have a little proposal for supporting the use of a KEY expression in > the FROM clause and I'd like to hear your opinion

[hibernate-dev] Extended KEY expression support

I have a little proposal for supporting the use of a KEY expression in the FROM clause and I'd like to hear your opinions on that. Unfortunately the JPA spec does not support that, but since a key of a java.util.Map mapping may be an entity type, we need to specify how one can "join" that key

Re: [hibernate-dev] Query#iterate

it didn't complicate the query parser. >> >> Vlad >> >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole <st...@hibernate.org> wrote: >> >>> Because the behavior is also fundamentally questionable. >>> >>> On Fri, Jan 27, 2017 at 12:1

Re: [hibernate-dev] Query#iterate

:01 schrieb Steve Ebersole: > On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > I just know of people that are using iterate() now for efficient > incremental processing, but I guess

Re: [hibernate-dev] boolean type support

Am 27.01.2017 um 17:31 schrieb Steve Ebersole: > Obviously that only works if there is not already an AttributeConverter > applied to to the attribute. I cannot imagine that ever happens in a > supported way, or a way that we want to support. Essentially that would > mean a condition where we

Re: [hibernate-dev] Query#iterate

I just know of people that are using iterate() now for efficient incremental processing, but I guess any other approach(streams maybe?) to do incremental processing would be good enough for these users. Unfortunately I don't know what a shallow query is or what the implication on the query or

Re: [hibernate-dev] 6.0 - Type system

e "hints" like accepting > PersistentAttribute/Navigable references, JPA (static) metamodel > references, etc. These are better, as they would include things like > AttributeConverter whereas the Type reference would not. > > > > On Mon, Jan 23, 2017 a

Re: [hibernate-dev] 6.0 - Type system

Since custom JavaTypeDescriptors and SqlTypeDescriptors can be used instead, I'm also for removing it. Am 23.01.2017 um 15:45 schrieb andrea boriero: > trying to find a valid reason to keep UserType but not able, so I'm for > removing it. > > On 23 January 2017 at 14:36, Vlad Mihalcea

Re: [hibernate-dev] 6.0 - Session#createFilter

, Jan 2, 2017 at 2:40 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > Let's say we have this entity with an attribute that is not > directly exposed. > > class EntityA { String field; } >

Re: [hibernate-dev] 6.0 - Session#createFilter

ut > not expose it? And btw even create createFilter would not work there > because you have to pass createFilter the collection > > > On Mon, Jan 2, 2017, 2:15 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > >

Re: [hibernate-dev] 6.0 - Session#createFilter

t; On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > Sounds good to me, but maybe we could do a poll to see if people are > using this? I don't know if the filter also works for field

Re: [hibernate-dev] 6.0 - Query literal rendering

May I ask what happened to the idea of not rendering through the literals at all and just "inject" them into the result tuple? We could even go as far as allowing expressions on constant values to be evaluated in memory instead of sending that to the DB. Other than that, the settings seem ok,

Re: [hibernate-dev] 6.0 - Session#createFilter

Sounds good to me, but maybe we could do a poll to see if people are using this? I don't know if the filter also works for field based access strategy, but that could be a reason for keeping it around. Regards, Christian Am 31.12.2016 um 21:00 schrieb Steve Ebersole: > As I have not been

Re: [hibernate-dev] SQM - PoC design doc

ubclassTable specialization. So far that is still hitting > some problems. > > > On Wed, Dec 21, 2016, 2:36 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> > wrote: > > I tried to think of a case wh

Re: [hibernate-dev] SQM - PoC design doc

I tried to think of a case where returning the union-query as table would enable optimizations, but so far I couldn't come up with anything. With the other approach, depending on the stage this optimization should happen, it might be pretty simple to omit columns of table references and

Re: [hibernate-dev] SQM - PoC design doc

I tried to think of a case where returning the union-query as table would enable optimizations, but so far I couldn't come up with anything. With the other approach, depending on the stage this optimization should happen, it might be pretty simple to omit columns of table references and

Re: [hibernate-dev] AutoCloseable is great.. what about JPA?

Hey Jordan, maybe what you are looking for is Blaze-Persistence Entity Views? https://github.com/Blazebit/blaze-persistence#entity-view-usage Query caching should work since it builds on top of scalar queries, but lazy loading is something I don't support and honestly don't think will support.

[hibernate-dev] PR for HQLPARSER-15

Hello, I prepared another PR for a very old issue: https://github.com/hibernate/hibernate-orm/pull/1577 The PR contains a testcase and the fix for the issue(https://hibernate.atlassian.net/browse/HQLPARSER-15) Regards, Christian ___ hibernate-dev

Re: [hibernate-dev] HHH-9329

gt; I can tell by your reaction that you really were asking whether *your* > change would be integrated upstream, but that was not obviously from > your email :) > > > On Fri, Sep 23, 2016 at 12:32 PM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gm

Re: [hibernate-dev] HHH-9329

ainly whether that leads to > any non-compatible SPI changes. > > > On Fri, Sep 23, 2016 at 11:41 AM Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > Ahh okay, I see. Sorry, I didn't fully read my previous mail and &g

  1   2   >