|
Hi,
I'd also like to add set operations like UNION to JPA, and since
the Hibernate Team will likely add that in Hibernate 6.0 we'd have
a compatible implementation soonish. I have also implemented
support for set operations in Blaze-Persistence, a library on top
of JPA, but UNION and other set operations only work with
Hibernate for now.
I'm still not sure about the process though. As far as I know,
there is JPA provider version that supports UNION yet, so I guess
the specification efforts will live on a PR until a compatible
implementation comes along? Or is that only relevant for the final
release?
Also +1 for JSON support. It would be cool if JSONB could provide
a metamodel, then JPA could make use of that to even support types
within JSON documents.
Am 06.11.2019 um 08:48 schrieb Behrang
Saeedzadeh:
Hi all
I try to get more engaged here. Right now off
the top of my head, I was thinking about discussing the
possibility of adding support for UNION to JPQL/Criteria.
It sometime can lead to significant performance
improvement as some planners struggle optimizing a query with
many joins but do fine when the query is split into two where
results are combined using UNION.
Another feature was the possibility of declaring
associations with Streams instead of Collections, with
semantics that would allow iterating over millions of rows
without eating too much memory.
Also now that some RDBMSes have first class
support for JSON, letting users inttospect JSON fields and use
them in WHERE clauses, adding support to JPQL/Ctiteria would
be nice.
I am adding
a few folks here that could help mentor and kick-start this.
I myself frankly can only guess at this point. However, I
would say all
of this is new so starting just about anywhere is fine.
Additional responses below. I have removed extra text for
brevity.
Reza Rahman
Principal Program Manager
Java on Azure
Please note views expressed here are my own as an individual
community
member and do not reflect the views of my employer.
On 11/2/2019 9:04 AM, Christian Beikov wrote:
>
> I think there are lot's of issues in the issue tracker
that could be
> tackled, but at this point I am not sure about how to
start.
>
I suggest starting by triaging the issues here together.
> Are the discussions about the big bang namespace change
already over?
>
There is still some churn but looks like things are very, very
slowly
gravitating towards big bang. I believe the community stepping
up to
move things forward will accelerate these decisions.
>
> Is it even possible to add features in such a seemingly
> "namespace-change-only" release?
>
Likely not.
>
> What needs to be done to actually add a feature? Is a PR
containing
> the spec and API changes enough? I guess a TCK test would
have to be
> added as well? How is the decision made that a feature is
added?
>
Anything that can be done is progress. In order for something
to be
considered complete, it likely needs an API change, change in
one of the
implementations, a TCK change and a spec document change. They
don't all
need to be done by the same people. The project committers and
lead
decides if a change will be made - effectively that means all
of us
together. Given the state of things, I would say most
reasonable changes
should make it in. It is contributing that actually matters.
>
> It would be great if we could illustrate the process with
a more or
> less simple issue(https://github.com/eclipse-ee4j/jpa-api/issues/163)
> so that people get a feeling for how the specification
can be shaped.
>
As long as you have the paperwork set up, I would say there is
nothing
stopping you from doing exactly that.
_______________________________________________
jpa-dev mailing list
jpa-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jpa-dev
|
