search

quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.82k stars 2.69k forks source link

EclipseLink #6801

Open sniew opened 4 years ago

sniew commented 4 years ago

Description (Describe the feature here.)

Could you please add support to eclipselink ORM

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

mann-ed commented 4 years ago

This is a feature i would like as well. I have several Thorntail apps i would like to move over to Quarkus, but i don't want to switch to using hibernate as JPA provider. I could help if had some guidance on implementing this.

ia3andy commented 4 years ago

@maxandersen this one has 4 likes, I don't know about EclipseLink ORM. Would it be an extension? Maybe we should move that one to the Quarkus core repo?

maxandersen commented 4 years ago

yes, this is for quarkus core repo.

maxandersen commented 4 years ago

worth stating here that making hibernate work with graalvm and be superfast to boot up in Quarkus was not a small feat requiring intimidate knowledge about Hibernate. We don't have such knowledge about EclipseLink thus this isn't something we would be able to do without the EclipseLink community/committers driving it.

Sanne commented 4 years ago

I don't think we'll be able to do this: getting Hibernate ORM to work fine was a massive amount of work, and it's not econimically wise to spend the same effort on another project which would essentially provide the same / very similar feature.

Sorry but I'll close this, anyone feel free to do this outside of the Quarkus repository.

Is there any specific reason you need EclipseLink and couldn't just use Hibernate ? If so, please list the details.

emmanuelbernard commented 4 years ago

I am reopening this issue to let everyone vote for interest. And also see if someone is willing to implement an eclipse link extension. The existing contributors will not spend time on it though for the reasons stated above. This is going to be significant work on both eclipse link and the extension itself. It will also likely require extra work in how Quarkus handles JPA providers.

I don’t think it needs nor should be in the Quarkus core repo (as was stated above). This would live in its own repo.

Sanne commented 4 years ago

Well ok I'm not against having more comments. But if you agree it doesn't belong in this repository, then we'll need a way to not have such issues get stale here either.

For the record, if anyone wants to try getting EclipseLink to work: my main concern is that you'll have to know its internals very well, and likely contribute some rather invasive patches to the project to get it to work in native-image .

emmanuelbernard commented 4 years ago

Today the quarkus issue is for the whole platform unfortunately. Got to live with that I don't see any obvious way around it that would not make life harder. Issues don't get stale anymore except when they come from code.quarkus.io for some reason. Also extension-proposal would be naturally excluded from a stale process (or should).

hosseinmp76 commented 4 years ago

Is there any specific reason you need EclipseLink and couldn't just use Hibernate? If so, please list the details.

the only reason I see is that EclipseLink has moved to Jakarta ee namespace(it's still beta) but there is no clue on hibernate when it will migrate(its sill on v6 development)

Sanne commented 4 years ago

Is there any specific reason you need EclipseLink and couldn't just use Hibernate? If so, please list the details.

the only reason I see is that EclipseLink has moved to Jakarta ee namespace(it's still beta) but there is no clue on hibernate when it will migrate(its sill on v6 development)

Ironically, we haven't updated Hibernate to Jakarta EE because it wouldn't work in Quarkus unless all other technologies to integrate with also switched at the same time (to avoid a mess).

We could explore doing this, but your comment is the first I've seen asking for it.

sniew commented 4 years ago

For legacy reason i use eclipselink instead of hibernate for the support of dynamic entities.

TFyre commented 3 years ago

Ran into quite some issues trying to use Hibernate instead of Eclipselink... Some of the items are the following:

Sanne commented 3 years ago

Thanks for the information! Appreciate hearing the reasons, although I don't understand them all fully yet so I hope you (all) don't mind me asking more details.

To follow up on the previous comment regarding Jakarta EE, that is available in Hibernate now as well:

But as I mentioned, that doesn't imply it's going to be easy to swap in Quarkus as the other components need also all be aligned on the same spec API. That implies supporting EclipseLink instead won't help either.

Ran into quite some issues trying to use Hibernate instead of Eclipselink... Some of the items are the following:

  • entity listeneners (using prePersist / PostUpdate / PostRemove)

@TFyre could you elaborate on that? I know we have some well documented limitations regarding such events in native (and in native only) not being fired, but then EclipseLink doesn't work at all in native so I suppose you're not referring to that limitation in particular. So I'm not sure what is problematic?

Please open a separate issue, we'll look at it.

Incidentally, even the limitation we have on firing these in native image is totally solveable - it just happens to be something we haven't prioritized, especially as it seems noone is really asking for it. (are you?)

  • lazy loading of readonly outside of session (hibernate.enable_lazy_load_no_trans doesnt hydrate the entity properly and throws org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)

We can look into this as well. I won't prioritize this one very highly as I don't think it's a good idea to load things out of transaction, but if you open an issue and provide a reproducer that would be a great way to persuade me to give it more attention.

TFyre commented 3 years ago
  • entity listeneners (using prePersist / PostUpdate / PostRemove)

I am referring to the documented JPA Callback section https://quarkus.io/guides/hibernate-orm#limitations

not sure if this has now been solved with Jakarta certification?

If there are any work-arounds for this, documenting / referencing it would be awesome!

  • lazy loading of readonly outside of session

Will look into logging this as an issue

Sanne commented 3 years ago

@TFyre many thanks. And yes the limitation I've documented at https://quarkus.io/guides/hibernate-orm#limitations isn't really a limitation of Hibernate ORM but of how things need to be re-wired in Quarkus. It wouldn't work out of the box in EclipseLink either, and we can certainly look at finally removing this specific limitation - it's a left over from the initial POC.

Sanne commented 3 years ago

If there are any work-arounds for this, documenting / referencing it would be awesome!

BTW a simple workaround is to not compile to native.. not sure if that's your goal, but it should work just fine in JVM. It's listed as a limitation as we don't want to muddy the waters about certain things only working on one VM and not the other... really needs parity for us to consider a feature "available".