Hello!
I have a strange problem, which I don't have in my company related to
the usage of mapped superclasses.
I have a base entity which encapsulates the id like this:
@MappedSuperclass
public abstract class SimpleEntityT extends Serializable implements
Serializable {
private static
this?
--
Mit freundlichen Grüßen,
--------
*Christian Beikov*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
see my comments inline...
>
>
> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov
> <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote:
>
>
> * Missing support for treated paths like "TREAT(...).property"
> in the
>
subclass attribute
> references). In a way you can think of HQL as offering TREAT support
> implicitly.
>
>
> With all that in mind, see my comments inline...
>
>
> On Wed, Aug 3, 2016 at 9:43 PM Christian Beikov
> <christian.bei...@gmail.com <mailto:christian.b
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
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
: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
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
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
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
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
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
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
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
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
ior.
> Regards,
> Gail
> [1] https://msdn.microsoft.com/en-us/library/ms188048.aspx [2]
> https://technet.microsoft.com/en-us/library/ms187831(v=sql.105).aspx
> <https://technet.microsoft.com/en-us/library/ms187831%28v=sql.105%29.aspx>
>
>
> On Thu, Sep 1, 2016 at 3:1
Well the BNF in the JPA 2.1 spec contains
"collection_valued_input_parameter" which resembles this parameter list,
so dropping support for that would make Hibernate non JPA compliant I guess.
If you are concerned with caching, I think the parameter lists could be
expanded to a
of the semantic of the query... the ability to answer
> such questions...
>
>
> On Sat, Sep 10, 2016 at 7:34 AM Christian Beikov
> <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote:
>
> May I ask how the semantics of a query could chang
atementSelect sqm = SemanticQueryInterpreter.interpret(...);
>
> // now we have to delay creation of the QueryPlan until later
> // because we do not know if the query is cacheable, because
> // we do not know yet whether it contains any multi-valued
>
Ah ok, I thought you wanted to drop parameter lists in general ^^
I suppose you are discussing this because of
https://hibernate.atlassian.net/browse/HHH-10502?
I personally don't have a use case for a general parameter list
expansion like the reporter of that issue and I also don't think that
if the query is cacheable, because
> // we do not know yet whether it contains any multi-valued
> // parameters.
>
> return new QueryImpl( sqm, this );
> }
>
>
>
> On Fri, Sep 9, 2016 at 4:17 PM Christian Beikov
> <christian.bei...@gmail.com <mailto:c
My idea was to allow a parameter to be a collection valued parameter
only in two cases
1. When used with the IN predicate
2. When used as last argument for a function and the parameter is a
var-arg parameter
That way the query can be validated upfront when knowing the registered
I'd say one can either use the "new .." syntax, or a
ResultTransformer/TupleTransformer but not both at the same time.
IMO you can do your DTO stuff in the transformer which is probably also
one of the few usecases for ResultTransformer.
Am 13.09.2016 um 01:33 schrieb Steve Ebersole:
> If we
?
Regards,
Christian Beikov
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Thanks Vlad,
and for what it's worth, the tests for H2 run through.
Am 19.09.2016 um 17:10 schrieb Vlad Mihalcea:
> I can take a look on it tomorrow and let you know.
>
> Vlad
>
> On Mon, Sep 19, 2016 at 5:50 PM, Christian Beikov
> <christian.bei...@gmail.com <mailto:ch
ing critical issues and regressions to 5.0 at this
> point, so it can't be backported to 5.0. If no regressions caused by
> this fix are reported in 5.2, I would consider backporting to 5.1.
>
> Regards,
> Gail
>
> On Wed, Sep 21, 2016 at 12:14 AM, Christian Beikov
> <christian.bei..
w you configure caching. If
> you try to reuse regions for different types of data (entity,
> collection, etc) then it will affect you. If you define different
> access strategies for the same region then it will affect you.
>
>
> On Fri, Sep 23, 2016 at 1:02 AM Christian Beik
ome other "Hibernate 5.1+ and Infinispan"
> problem, then I guess you could have been more specific ;)
>
>
>
> On Fri, Sep 23, 2016 at 11:33 AM Christian Beikov
> <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote:
>
>
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
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
Hey again,
I implemented the approach that I proposed in the issue and a test in
https://github.com/hibernate/hibernate-orm/pull/1561
It detects left joins with join tables that use the target table alias.
The join table is replaced with a subquery and the WITH clause is moved
to the join of
> sure how else you would possibly do this
>
>
> On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea
> <mihalcea.v...@gmail.com <mailto:mihalcea.v...@gmail.com>> wrote:
>
> Thanks,
>
> I'm going to review it tomorrow.
>
> Vlad
>
&
assert anything useful right now.
Regards,
Christian
Am 09.08.2016 um 13:14 schrieb Christian Beikov:
> Hello again,
>
> I finished the first part of the test cases for root treats and
> many-to-one treats. I also tried to explain how I would expect treat
> to work and present a
browse/HHH-11062
>
> Best regards,
> Emond
>
> On dinsdag 23 augustus 2016 11:07:22 CEST Christian Beikov wrote:
>> Hi,
>>
>> so I finished my work on the testsuite
>> <https://github.com/beikov/jpa-treat-variations> for the treat operator.
>&
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
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.
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,
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
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
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:
>
>
, 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; }
>
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
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
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
+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
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
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
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
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
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,
>
>
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
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
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
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
,
*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
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
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
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
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
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
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
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,
------
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
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
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
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
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
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
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
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
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
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.
,
*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
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
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,
>
>
+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
.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
, 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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
t;>> }
>>> else {
>>> commonPersistentClass = commonPersistentClass.getSuperclass();
>>> commonMappedSuperclass = null;
>>> }
>>>}
>>> }
>>>
>>> As you can see the commonMappedSuperclass is not initialized and s
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`
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
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
+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
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
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
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
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:
>
1 - 100 of 121 matches
Mail list logo
