On 26 August 2016 at 16:28, Davide D'Alto wrote:
> I published an initial post on staging:
> http://staging.in.relation.to/2016/08/26/should-we-drop-rest-for-neo4j/
>
> I'm not sure how should I ask the user about it, let me know what you think.
> Also, is there a way we prefer to generate poll fo
I published an initial post on staging:
http://staging.in.relation.to/2016/08/26/should-we-drop-rest-for-neo4j/
I'm not sure how should I ask the user about it, let me know what you think.
Also, is there a way we prefer to generate poll for the website or I
can just rely on the comment?
This one
I doubt we'd see JPA EnumType expanded, but it never hurts to propose
something.
I did some digging and of the major dbs it seems that only PGSQL supports
enums as a proper data type. The difficulty is handling these through
JDBC. Just do a web search for "pgsql enum jdbc" and you'll find all th
On 26 August 2016 at 12:35, Emmanuel Bernard wrote:
> On Fri 2016-08-26 11:32, Gunnar Morling wrote:
>> > How much additional work would it be to keep the "old" rest in a legacy
>> module separated from the pure one?
>> > Does it even make sense?
>>
>> As a user, when would I prefer which one over
On 26 August 2016 at 12:51, Steve Ebersole wrote:
> PGSQL has some enum support I know. The problem has always been that they
> are mapped to "special" type codes (think java.sql.Types) which makes it
> difficult to work with in ORM.
That's very interesting. So in an ideal world, could we propos
PGSQL has some enum support I know. The problem has always been that they
are mapped to "special" type codes (think java.sql.Types) which makes it
difficult to work with in ORM.
On Fri, Aug 26, 2016 at 6:18 AM Gunnar Morling wrote:
> > I guess we could, but it's sad that we'd still have to de
On Fri 2016-08-26 11:32, Gunnar Morling wrote:
> > How much additional work would it be to keep the "old" rest in a legacy
> module separated from the pure one?
> > Does it even make sense?
>
> As a user, when would I prefer which one over the other? If Bolt is the
> general recommendation, I'd li
> I guess we could, but it's sad that we'd still have to default to the
> "wrong" mapping,
> at least for all those people who won't read all of our docs.
The default for our custom @Enumerated could be NATIVE, but I agree people
need to know about that instead of the JPA one.
> Would that live i
> How about having a custom @Enumerated annotation which offers NATIVE as an
> additional choice?
This is probably the approach I would prefer, it seems consistent with
what we already do with Hibernate Annotations.
For example, org.hibernate.annotations.Table and javax.persistence.Table.
Could
On 26 August 2016 at 10:34, Gunnar Morling wrote:
> How about having a custom @Enumerated annotation which offers NATIVE as an
> additional choice?
I guess we could, but it's sad that we'd still have to default to the
"wrong" mapping,
at least for all those people who won't read all of our docs.
How about having a custom @Enumerated annotation which offers NATIVE as an
additional choice?
2016-08-26 10:16 GMT+02:00 Emmanuel Bernard :
> Can you give HotRod's example of native enum - I imagine Protobuf ?
>
> The issue I see is that ordinal could be an acceptable explicit decision
> that wou
> How much additional work would it be to keep the "old" rest in a legacy
module separated from the pure one?
> Does it even make sense?
As a user, when would I prefer which one over the other? If Bolt is the
general recommendation, I'd limit efforts on this one. It seems to be one
of those knobs
Can you give HotRod's example of native enum - I imagine Protobuf ?
The issue I see is that ordinal could be an acceptable explicit decision
that would not be available to the user if you use default as native.
I'm tempted to go native all the time at the detriment of people that
need high custom
Can you write a blog post with a small poll to know if anyone complains
about dropping REST. Let's have it on for a week and make a decision. If
nothing conclusive comes out, let's drop it.
On Fri 2016-08-26 8:27, Davide D'Alto wrote:
> > Thinking out loud. How much additional work would it be to
Cool.
I've created a new 5.3 branch on GitHub and a 5.3.0.CR1 version in JIRA.
The version on master is 6.0.0-SNAPSHOT now.
--Gunnar
2016-08-26 8:30 GMT+02:00 Emmanuel Bernard :
> Good plan.
>
> > On 24 août 2016, at 09:11, Gunnar Morling wrote:
> >
> > Hi,
> >
> > Now that the first changes
> Thinking out loud. How much additional work would it be to keep the "old"
> rest in a legacy module
It would still require to be maintained, I would prefer not to have it
unless there is a specific use case for it
>. Does Bolt run atop HTTP as I remember it
I don't think so, it's a binary pro
Because we likely have more breaking changed planned in 6.0, I don't think your
renaming plan would add a lot. Better focus on 6.
> On 18 août 2016, at 14:42, Scott Marlow wrote:
>
>
>> On 08/17/2016 03:54 PM, Steve Ebersole wrote:
>> For whatever reason discussion about JavaMoney/Moneta supp
17 matches
Mail list logo
