-
Notifications
You must be signed in to change notification settings - Fork 61
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
programmatic result set mappings for native queries #9
Comments
@glassfishrobot Commented |
@glassfishrobot Commented |
|
Even though this is issue #9, from 2011, it's actually been quite near the top of my priority list for quite a long time. We absolutely need an API-based way to define SQL result set mappings! |
How about something like this: Result.Entity<Order> orderResultMapping =
Result.entity(Order.class,
Result.field(Order_.id "order_id"),
Result.field(Order_.quantity, "order_quantity"),
Result.field(Order_.item, "order_item")
);
Query<Order> query = entityManager.createNativeQuery("...", orderResultMapping); The class There would also be:
Now, with use of static imports, the above code would simplify to: Entity<Order> orderResultMapping =
entity(Order.class,
field(Order_.id "order_id"),
field(Order_.quantity, "order_quantity"),
field(Order_.item, "order_item")
);
Query<Order> query = entityManager.createNativeQuery("...", orderResultMapping); Hell, we could even in principle have |
On Twitter the idea of using string templates was suggested by Gunnar Morling. I believe it would be possible to make something like this work: NativeQuery query =
NATIVE."select o.id as \{Order_.id}, o.quantity as \{Order_.quantity}, o.item as \{Order_.item} from orders o";
Query<Order> query = entityManager.createNativeQuery(query); Of course, something quite a bit more complicated would be needed to handle multiple instances of the same entity in the result set, embeddables, etc. And ultimately this would probably end up needing some sort of "dynamic" result set mapping API. Now, I know that looks like a completely different feature to the one proposed in the issue description, but my intuition is that this is actually a better solution to the most common use cases for a result set mapping API. Anyway, the point is that we should keep this application in mind in the design of a result set mapping API. |
See #691. |
API for specifying result type mappings. Currently this is handled through metadata, and is therefore static
The text was updated successfully, but these errors were encountered: