Hi Steve,
Did you ever have a chance to apply the "decorated parse tree" approach to
your Antlr4 PoC?
What I like about the Antlr4 approach is the fact that you don't need a set
of several quite similar grammars as you'd do with the tree transformation
approach. Also using the current version of
On 9 June 2015 at 09:56, Gunnar Morling wrote:
> Hi Steve,
>
> Did you ever have a chance to apply the "decorated parse tree" approach to
> your Antlr4 PoC?
>
> What I like about the Antlr4 approach is the fact that you don't need a set
> of several quite similar grammars as you'd do with the tree
2015-06-09 12:49 GMT+02:00 Sanne Grinovero :
> On 9 June 2015 at 09:56, Gunnar Morling wrote:
> > Hi Steve,
> >
> > Did you ever have a chance to apply the "decorated parse tree" approach
> to
> > your Antlr4 PoC?
> >
> > What I like about the Antlr4 approach is the fact that you don't need a
> s
Hi,
just wondering whether there are reasons or preferences for choosing
GitHub vs CloudFront for hosting the new blog site?
See also https://hibernate.atlassian.net/browse/WEBSITE-311
--Hardy
pgpuY07sIEpoO.pgp
Description: PGP signature
___
hibern
For our use case, bytecode enhanced reference cached immutable entities,
our top object for memory allocation is EntityEntry.
We see an EntityEntry object created every time an immutable entity is
added to a persistence context.
In our use case, where we know the entity is immutable and we alre
There are lots of setters on EntityEntry, but sharing it would require
at least the implementation to be fully immutable to be threadsafe.
I see three options for the custom EntityEntry implementation:
- simply ignore any write method by implementing each method as a no-op
- throw exceptions on
On 09/06/15 13:14, Sanne Grinovero wrote:
> There are lots of setters on EntityEntry, but sharing it would require
> at least the implementation to be fully immutable to be threadsafe.
>
> I see three options for the custom EntityEntry implementation:
> - simply ignore any write method by impleme
Hi!
A time ago I created this issue. The problem is this:
When using lazy extra and enabling filters affecting the collection, the
size() and isEmpty() methods are not applying the filters when the
collection proxy isn't initialized.
So, enabling filters and accessing a collection marked as lazy
2015-06-08 23:33 GMT+02:00 Steve Ebersole :
> >
> > I know personally, time/resources aside, the biggest reason I have not
> > worked a lot on the bigger task (other than my initial work on the new
> > query parser) is because I had hoped a solution would present itself to
> the
> > Antlr 4 quanda
On Tue, Jun 9, 2015 at 3:57 AM Gunnar Morling wrote:
What I like about the Antlr4 approach is the fact that you don't need a set
> of several quite similar grammars as you'd do with the tree transformation
> approach. Also using the current version of Antlr instead of 3 appears
> attractive to me
>
> If we come to the conclusion that tree transformation is vital, then yes,
> I don't see another way than going with Antlr3 (see my reply to the other
> thread on that). Apart from looking into alternatives to Antlr altogether,
> but I don't feel that's a realistic option.
>
Lets keep this disc
On 9 June 2015 at 13:50, John O'Hara wrote:
> On 09/06/15 13:14, Sanne Grinovero wrote:
>>
>> There are lots of setters on EntityEntry, but sharing it would require
>> at least the implementation to be fully immutable to be threadsafe.
>>
>> I see three options for the custom EntityEntry implement
On 09/06/15 15:30, Sanne Grinovero wrote:
> On 9 June 2015 at 13:50, John O'Hara wrote:
>> On 09/06/15 13:14, Sanne Grinovero wrote:
>>> There are lots of setters on EntityEntry, but sharing it would require
>>> at least the implementation to be fully immutable to be threadsafe.
>>>
>>> I see thre
On Tue, Jun 9, 2015 at 5:50 AM Sanne Grinovero wrote:
Do you mean that you would be ok to "navigate" all the [DOT] nodes to
> get to the decorated attachments?
> In that case while you might be fine to translate each fragment into a
> different fragment, it's not straight forward to transform it
Sanne, the phrase ImmutableEntityEntry was meant to convey that it is the
entry corresponding to an immutable entity. Maybe something like
NonUpdateableEntityEntry would be better. At any rate the javadocs need to
be redone there. The javadocs on ImmutableEntityEntry were left there from
when it
2015-06-09 16:02 GMT+02:00 Steve Ebersole :
> On Tue, Jun 9, 2015 at 3:57 AM Gunnar Morling
> wrote:
>
> What I like about the Antlr4 approach is the fact that you don't need a
>> set of several quite similar grammars as you'd do with the tree
>> transformation approach. Also using the current ve
On Tue, Jun 9, 2015 at 10:14 AM Gunnar Morling wrote:
Yes, indeed I cheated here a bit. Probably it should be the following
> instead:
>
> [DOT] ---> AttributeReference("", "code")
> [DOT]
> [DOT]
> [IDENT, "c"]
> [IDENT, "headquarters"]
>
See my comment on the Jira. We can discuss this on IRC if you wish.
On Tue, Jun 9, 2015 at 6:51 AM andrea boriero wrote:
> Hi Steve,
>
> I'm getting crazy with https://hibernate.atlassian.net/browse/HHH-9636
> JPA pessimisticLockScope.EXTENDED
>
>1. EntityManage#lock
> 1. LockMode.PE
So today I spent some time cleaning up the basic HQL parser. Personally I
think it would be best if our 2 proof-of-concepts could share that first
grammar. IMO that would make the differences between the 2 approaches more
apparent. I will push those changes soon.
It is not complete yet. But it
19 matches
Mail list logo
