-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JPA orm.xml file handling to support multiple database vendors #14762
Comments
@mgwillem can you provide a sample |
Here is an example of such orm.xml file for the SQLServer support <?xml version="1.0" encoding="UTF-8"?>
<entity-mappings
xmlns="http://java.sun.com/xml/ns/persistence/orm"
version="2.0">
<description>Override Annotations...</description>
<persistence-unit-metadata>
<persistence-unit-defaults>
<schema>dbo</schema>
</persistence-unit-defaults>
</persistence-unit-metadata>
<entity class="org.foo.Foo" access="FIELD" metadata-complete="false">
<attributes>
<id name="id">
<generated-value strategy="IDENTITY" />
</id>
</attributes>
</entity>
<entity class="org.foo.Bar" access="FIELD" metadata-complete="false">
<attributes>
<id name="id">
<generated-value strategy="IDENTITY" />
</id>
</attributes>
</entity>
</entity-mappings> |
I agree we should do this, but let me clarify some restrictions:
I hope that's agreable? |
Yes the Do you think we could define a "milestone" for this feature request ? |
Hi ! I'm curious to know if this |
I must admit I'm not sure about the timeline. There's a couple more urgent tasks that my team needs to finish first, and I personally need to take some time off - so it depends if I can delegate this one, but it's not simple to do as far as I remember from the initial POC :) But that's been a couple years ago so I suppose it's possible that this is much simpler noways, as our tools improved and we have a better understanding of GraalVM we have today. I'll try a better estimate next week; ideally if I can get a better picture and delegate this to another team member it is more likely to get done quickly. |
Thanks @Sanne for your update! I hope it will be easier to implement than expected :) |
Hi! Any news regarding this feature support? Thanks |
So this basically means there is no way to use entities from external libraries with JPA in Quarkus? This is bad. |
@mgwillem sorry I'm the slow cog here. @yrodiere volunteered to take it over. @sithmein if by "external libraries" you mean 3rd party classes which can't be annotated, then yes there's this current limitation, but it shouldn't be too hard to fix. At least, conceptually, there's nothing fundamentally hard about it other than someone needing to do the work of wiring up the existing support of Hibernate ORM to our custom bootstrap code. HTH |
@mgwillem Could you please detail what your classpath looks like? What are the JARs involved, where are the The JPA spec allows many different setups, and it gives the tools to achieve these setups by allowing a But currently, we don't support that in Quarkus, so we can end up including Here are the use cases that I can think of:
Use cases 1 and 2 can be covered easily (barring any problem with the XML parsers, but that's another matter). Use case 3 requires the configuration of the persistence unit through a Use case 4 cannot be addressed unless we add support for assigning JARs to a persistence unit, so that we can filter out irrelevant |
by spec 8.2.1 the default name would be So I'd say you don't have to implement "case 4" as that was never supported in other systems either. |
I wish :)
Taken from the ORM documentation, quoting the spec: https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#bootstrap-jpa-xml-files |
@yrodiere I don't understand your point for "I wish" - could you clarify? It seems to me that it's avoiding ambiguity, what am I missing? |
Sorry if that wasn't clear, my point was just below. By spec, So from my understanding, this JAR content is spec-compliant:
Same with custom (non-default) file names:
Looking at the (complex) code that handles JARs and entity/resource scanning in ORM, it does seem to handle this kind of setup. I can tell that we won't be able to provide something that is both simple (flat classpath, simple entity/resource scanner) and adheres to the spec. And that's fine I guess, we don't want to handle every single legacy quirk that JEE allows, but then the whole of this issue was to support legacy setups, so I'm not sure where we should draw the line :) I'll start with a simple implementation where we just look for mapping files everywhere, and fail if there are multiple resources for a given mapping file name. That should cover use cases 1 and 2. Then I'll see about use case 3: when looking for a mapping file, I'll consider that a file in the same JAR as the That should be a decent compromise, I think. And anyway, we cannot support more without supporting |
Sorry for the late response.
My use case is the following:
I've 2 legacy libraries, let's call them libA.jar and libB.jar, that are
used by my application.
Compiled for Oracle ... both libA and libB do not contain any
META-INF/orm.xml file.
Compiled for MSSQL ... both libA and libB contain META-INF/orm.xml files
(to override schema and PK generated value [from sequence to identity]).
persistence.xml do not reference the META-INF/orm.xml file as it is
automatically detected by JPA.
Does it answer to your question ? :)
Marc
Le jeu. 18 mars 2021 à 14:10, Yoann Rodière ***@***.***> a
écrit :
… @mgwillem <https://github.com/mgwillem> Could you please detail what your
classpath looks like? What are the JARs involved, where are the orm.xml
files and there persistence.xml files, and which persistence.xml file
references which orm.xml file?
The JPA spec allows many different setups, and it gives the tools to
achieve these setups by allowing a persistence.xml to specify a list of
JARs.
But currently, we don't support that in Quarkus, so we can end up
including orm.xml files that shouldn't be included. And that's a very
real problem: if a META-INF/orm.xml file in the classpath defines a
default schema, you definitely don't want to apply it to the wrong
persistence unit.
Here are the use cases that I can think of:
1. Single-JAR application, configured through either
application.properties or persistence.xml.
2. Multi-JAR application configured through either
application.properties or persistence.xml, where the orm.xml files
have unique names across all JARs.
3. Multi-JAR application configured through a persistence.xml, where
the orm.xml files may not have unique names, but are always located in
the same JAR as the corresponding persistence.xml.
4. Multi-JAR application where the orm.xml files do *not* have unique
names, and are not necessarily located in the same JAR as the
persistence.xml they need to be used with, or are used in a
persistence unit that doesn't have a persistence.xml.
Use cases 1 and 2 can be covered easily (barring any problem with the XML
parsers, but that's another matter).
Use case 3 requires the configuration of the persistence unit through a
persistence.xml, but could be covered as well, as long as we have a way
to detect where each file (persistence.xml or orm.xml) comes from (which
JAR).
Use case 4 cannot be addressed unless we add support for assigning JARs to
a persistence unit, so that we can filter out irrelevant orm.xml files.
And from what I can see, that doesn't look like something we want to do...
@Sanne <https://github.com/Sanne>?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14762 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGPO56ZCSYN4NZEB5GWMPDTEH3WBANCNFSM4W6SIFXQ>
.
|
Almost, thanks. One remaining question: where is the |
In my use case there wouldn't be a |
Sure. I have that in mind too: allow listing mapping files in the Quarkus configuration. The legacy use cases are much more tricky though, so I'd like to know where the |
That seems like a very fine setup in Java EE where you have assemblies (EARs and WARs) that contain But do we have that sort of thing here? |
libA.jar and libB.jar contain one META-INF/persistence.xml file each.
In my use case the application jar does not contain any persistence file.
Le lun. 22 mars 2021 à 13:14, Yoann Rodière ***@***.***> a
écrit :
… In my use case there wouldn't be a persistence.xml at all because Quarkus
should set up everything.
Sure. I have that in mind too: allow listing mapping files in the Quarkus
configuration.
The legacy use cases are much more tricky though, so I'd like to know
where the persistence.xml file is in @mgwillem
<https://github.com/mgwillem> 's case...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14762 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGPO53PFAAIBHLOSGDITCLTE4YCNANCNFSM4W6SIFXQ>
.
|
No, we don't have So that was my point: I don't think we can (fully) support use case 4 without Maybe that's fine, maybe that's not; in any case, supporting the other use cases will be a lot of work already, so I'll stick to that for now. Fortunately for @mgwillem , it seems he doesn't need that as his
Alright, thank you! That's use case 3, then. |
I submitted a PR to support XML mapping: #16630 Anyone interested in the feature, please try it out and report about your results!
|
I do have the same problem now. I have a Hoping the PR will get in soon ;o) Let me know, I'm ready to test it if you need someone |
hi @agoncal ! Feel free to test the PR - it looks good, the reason for which it wasn't merged yet should not be a problem for you in practice. |
@Sanne I just gave it a try and it works! I had the following exception:
So I had to add the following to the
Works like a charm ! And best of the best, I can create a |
Thanks for testing @agoncal ; happy to see it works for you. Hopefully we'll get rid of the remaining metaspace problem soon (it may be unrelated, but it's blocking the PR pending investigation). Then we'll merge the PR. |
that Jandex error makes me think we might want to automatically add them to the index, if we can identify the artifact |
That would be awesome. As a developer I don't want to know this level of details of Quarkus internals. |
@Sanne Maybe. But we cannot add them to the index until we start processing the mapping files and going through the entity hierarchy. I suspect we cannot add them to the index at this point, otherwise this error message wouldn't be here in the first place? |
Created #17285 |
I found something weird.
When I add this
Now, if I customize the mapping, the name of the table, name of the columns, the length of the columns do get changed, but not the nullability (
Is my syntax right ? Am I doing something wrong or is the mapping not working correctly ? |
@agoncal This looks odd, though I doubt it's caused by Quarkus... Then again, looking at the ORM code, I don't see how Do you have a quick reproducer? If so, please open a ticket either for Quarkus or ORM, I'll try to debug it. |
@yrodiere Yes, I managed to reproduce it in a much simpler example https://github.com/agoncal/agoncal-bug-quarkus-orm |
@agoncal Thanks for the reproducer, I'm having a look right now. Sorry about the delay, there was quite a few issues to handle from last week. |
Description
I need to implement a solution that supports multiple database vendors like Oracle, MS SQLServer, DB2, etc.
Moreover I need to re-use existing "legacy" JARs containing JPA entities with annotations and orm.xml files.
Such "legacy" JARs are used by existing Java EE 8 applications.
Existing database schemas use sequences for Oracle PK and identities for SQLServer PK.
To handle such differences, we use annotations to define Oracle sequences .. and we use the orm.xml file to define MS SQLServer identities.
Moreover the orm.xml file is used for setting persistence-unit/schema as well. It means it is not only a PK override issue.
The orm.xml file is a standard JPA feature that is very useful (imho) and I believe this file support is mandatory for such use-cases.
Please keep in mind that migration of legacy apps/libraries is an important point here.
Thank you!
The text was updated successfully, but these errors were encountered: