Roland Mueller wrote:EclipseLink enhancements and extensions to JPA @OracleObject tells how to map an Oracle Object to fields in a Java class but this is an EclipseLink-specifc extension to JPA 2.0.
For Hibernat may be this article about custom types is useful.
Tim Holloway wrote:I looked a little closer and apparently custom data types are not in JPA, presumably because they'd break the write-once/run-anywhere paradigm that Java is predicated on.
I should also note that there is something deeply suspect about defining a complex data structure as a single database column, stored procedure or no. It kind of defeats the whole purpose of how relational databases work.
If you absolutely must, however, it might be worth considering adding a stored procedure that builds the structure from independent String parameeters. There's no obvious benefit I can see on the Java side to having a Java multi-property object in code, but passing it as what amounts to a binary unit to the database. Java is not C, where you're simply dealing with raw pointers and you definitely DON'T want to store such an item in Java Serialized form if you expect to be able to read it back 5 years later. There's no standard for Java serial format and they can and do change it from one JVM release to another.
Having said all that, when you said you found nothing in Baeldung, did that include this:
Tim Holloway wrote:I considered native queries, and you have a point, but there's relatively less potential breakage there. After all SQL has a standard, right? Snicker. Stored Procedures are much less portable relatively..
Please be patient, as it sometimes takes a while for me to get the idea behind things. Partly because so many questions here are posted by people who are trying to make things work in the way that they think they should work when there's actually a simpler way. Partly because I don't have the personality to notice everthing I should on the first 15 tries or so.
If you can do this in Spring Data JDBC, then I'd say that there's a high probability that Spring Data JPA can do it as well. Or at a minimum as a JPA Native Query. I'd avoid going to raw JDBC directly as it could get out of sync with JPA's caching mechanisms.
If I read your original post correctly (finally), you're not actually looking to pass a structured parameter to the stored procedure, but an array of structured parameters. That could be an issue in that JPA normally expects to deal with single parameters values per action. You might want to break the problem down into a single-value call and and see how that goes, then work up to a multi-value call.
Don't worry about boring me, If you can fit a decent explanation on one screen, that's enough. I don't need or want a complete source code listing or anything like that. Although error messages and stack traces are generally useful.
Tim Holloway wrote:Well, I'm glad you have a solution, although it sounds like your DBAs may not be comfortable with some of the more advanced options for performance and data integrity.
The first thing I think of when dealing with mixed multiple concurrent contributors is XA transactions.
A simpler approach used by Oracle Financials, for example, is not to apply work directly to the database, but to maintain a separate transaction table that you can contribute entries into with only minimal transaction control. That is, transactions are simple commits from a single app independent of what other apps may be doing. The database backend then pulls the transactions and applies them and in some systems, puts the applied transactions into an archive/history/playback table.
Also, at the risk of telling you something you already know, you should be able to atomically obtain unique IDs from Oracle's DUAL table without fear of ID collisions between multiple current contributors.