Hibernate reactive with panache exception when lazily loading a byte array #36211
Comments
quarkus-bot
bot
added
area/hibernate-reactive
|
/cc @DavideD (hibernate-reactive), @FroMage (panache), @Sanne (hibernate-reactive), @gavinking (hibernate-reactive), @loicmathieu (panache) |
|
Hi, which database are you using? Would it be possible to have a test project I can run? |
|
Sorry, I think I know what the problem is. |
|
Thanks! |
That's exactly right, but why is the error here so ugly? We should produce an LIE here and I thought we did. |
|
I've tried fetch the field with Mutiny.fetch(s.data), but had the same error, I don't know if there is another way |
|
At the moment, fetching lazy fields is not very user friendly if you are not using the JPA static metamodel. It's a whole area that needs some improvements from a usability point of view. |
I don't know if it helps, but I've created a small test project, if you run the test you can see the failure with the exception: |
|
For your particular use-case, because you only want the data field, I would use projections: @GET
@Path("/{id}")
@WithSession
public Uni<byte[]> download(@PathParam("id") long id) {
return StorageFile.<StorageFile>find("id", id)
.project( FileData.class )
.singleResult()
.map( FileData::getData );
}
@RegisterForReflection
public static class FileData {
private final byte[] data;
public FileData(byte[] data){
this.data = data;
}
public byte[] getData() {
return data;
}
}I've tested this with your code and it seems to work. |
|
I don't think it's possible with Panache to load lazy fields. You will have to use the session: private final Attribute<? super StorageFile, ?> dataAttribute;
public StorageController(Mutiny.SessionFactory sf) {
this.dataAttribute = sf.getMetamodel().entity( StorageFile.class ).getAttribute( "data" );
}
// ...
@GET
@Path("/{id}")
@WithSession
public Uni<byte[]> download(@PathParam("id") long id) {
return Panache.getSession()
.chain( session -> session
.find( StorageFile.class, id )
.call( file -> session.fetch( file, dataAttribute ) )
.map( file -> file.data )
);
}If you can enable the JPA static model generation in Quarkus (I don't know how to do it), it becomes: @GET
@Path("/{id}")
@WithSession
public Uni<byte[]> download(@PathParam("id") long id) {
return Panache.getSession()
.chain( session -> session
.find( StorageFile.class, id )
.chain( file -> session.fetch( file, FileStorage_.data ) )
);
}I've created an issue to make Quarkus generate the model automatically, but it has not been resolved yet. Keep in mind that using the fetch approach will cause the generation of two queries each time:
If you use projections, like I suggested in my previous comment, it will only run one query. I'm going to close the issue, but feel free to ask any follow up questions here. |
|
Thank you for your comments! |
|
So, @DavideD |
|
Exactly |
|
OK. Yeah, I suppose you can't make array subtypes that lazy load, you must lazy load in the accessor. |
Describe the bug
I have the following class, with a "data" field that is a byte array.
I need to load it lazily, but when I try to do it I have the following exception:
Looks like it's trying to directly cast CompletableFuture to the byte array, and I don't understand why or how to fix it.
If I change the "data" to FetchType.EAGER it works fine.
Just an example of how I'm loading the entity (It works fine with EAGER, only fails with LAZY loading the byte array) :
Expected behavior
Load a byte array lazily
Actual behavior
Exception class java.util.concurrent.CompletableFuture cannot be cast to class [B
How to Reproduce?
No response
Output of
uname -aorverLinux 5.15.90.1-microsoft-standard-WSL2
Output of
java -versionopenjdk version "17.0.7" 2023-04-18 LTS OpenJDK Runtime Environment Corretto-17.0.7.7.1 (build 17.0.7+7-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.7.7.1 (build 17.0.7+7-LTS, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.4.1
Build tool (ie. output of
mvnw --versionorgradlew --version)Maven 3.9.2
Additional information
No response
The text was updated successfully, but these errors were encountered: