>
> 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
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
Wow, the formatting on that came out awful. One more try
1. rework SQL generation & HQL parser
1. change JDBC extraction to work by position, rather than alias
2. port Hibernate Criteria constructs to JPA criteria, begin
deprecation of Hibernate Criteria
3. ability to over
Here is a list of tasks, with dependent tasks nested under the tasks they
depend on...
1. rework SQL generation & HQL parser
1. change JDBC extraction to work by position, rather than alias
2. port Hibernate Criteria constructs to JPA criteria, begin
deprecation of Hibernate
>
> - since I'm currently exploring the 2nd level cache keys and the
> persistence context keys again, it's getting clear (again as we
> discussed this before) to potentially use a different data structure
> to hold the persistence context.
>
The persistence context holds a lot of data, a lot of
>
> 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 quandary. But it hasn't and likely wont and I think Gunnar and
I think Andy wanted to take a look at developing just the support to
references values by position rather than by alias without waiting on the
bigger task. I don't think that is possible; at the least it is A LOT of
work much of which might change later when we do work on the bigger task.
I know
>
> * extend JPA criteria API with fluent support (does that mean embracing
> something like http://www.querydsl.com ? Os is that something different?
I was not the one who brought up "fluency". TBH, I do not remember who
brought it up nor what it was about.
In regards to Criteria I had wanted
On 20/05/15 02:47, Steve Ebersole wrote:
> Now that 5.0 is settling down I wanted to start planning where we go from
> here in terms of feature development and schedule/releases.
>
> Here is my high-level list of features/work:
> * rework SQL generation & HQL parser
> * change JDBC extraction to wo
That is actually exactly the model I started with 4.x and what I plan on
continuing into 5.x
On Fri, May 29, 2015, 3:07 AM Emmanuel Bernard
wrote:
> Also (thinking outloud).
>
> Maybe planning 5.1 5.2 5.x as a savant dosage of:
>
> - a focused and useful new feature that users tend to like
> (di
Guys "position rather than alias usage in JDBC" is a small part of a
massive set of related changes in how we build SQL and consume the
results. And actually it is the piece that has any compatibility impact
since it means any and all custom Types will need to be re-written.
On Fri, May 29, 2015
I agree as well :)
Just to add a minor twist:
- the override to lazy from eager would be useful to Search; skipping
fields completely as an extra bonus (something I think ORM can't do at
all - for good reasons when it comes to end user API - but again
something Search would benefit from and not e
On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
> Anyone have any input here? Or should I just start scheduling them how I
> want?
I think all goals sound good. I would say schedule as you seem fit, maybe
with a focus of giving users something tangible asap (a bit of what Emmanue
From a performance perspective, I'm glad we'll be able to override the EAGER
fetching on a query-basis. We could have an UNFETCH directive to do the
opposite of the current FETCH one.
The bytecode enhancement dirty-checking is also a plus.
Vlad
On Friday, May 29, 2015 11:09 AM, Emmanue
Also (thinking outloud).
Maybe planning 5.1 5.2 5.x as a savant dosage of:
- a focused and useful new feature that users tend to like (discriminator-based
multi-tenancy, fluent criteria API, …)
- a performance focused feature (position rather than alias usage in JDBC)
- a longer term work plan w
My favs are
* discriminator-based multi-tenancy
* extend JPA criteria API with fluent support (does that mean embracing
something like http://www.querydsl.com ? Os is that something different?
* rework SQL generation & HQL parser
> On 28 May 2015, at 18:33, Steve Ebersole wrote:
>
> Anyone h
Anyone have any input here? Or should I just start scheduling them how I
want?
On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole wrote:
> Now that 5.0 is settling down I wanted to start planning where we go from
> here in terms of feature development and schedule/releases.
>
> Here is my high-lev
Now that 5.0 is settling down I wanted to start planning where we go from
here in terms of feature development and schedule/releases.
Here is my high-level list of features/work:
* rework SQL generation & HQL parser
* change JDBC extraction to work by position, rather than alias (reworking
SQL gen
18 matches
Mail list logo
