I have a JPA entity named Child which extends another entity Parent.
I want a way of retrieving all Parent objects without any Child objects.
I am using Spring Data in my projects. I would also like to know if there are built-in or more appropriate ways of achieving this using Spring Data as well.
JPA supports polymorphic queries. It also supports limiting results to a particular type. It can be achieved with TYPE operator in WHERE clause of a query.
SELECT p FROM Parent p WHERE TYPE(p) = Parent
Related
When we use SQL with Spring boot, we can use hibernate and add #OneToMany relationships. It helps us to get the reference objects from another entity.
As an example, suppose Order and OrderDetails entities. When I query the Order entity, It automatically maps with the OrderDetails entity and it brings the whole document together. How can I do such a thing with Springboot+mongodb? Is there any easy way to solve this problem? Is it called ORM?
I have this situation:
Spring Data JPA: Work with Pageable but with a specific set of fields of the entity
It about to work with Spring Data and working with a specific set of fields of an #Entity
The two suggestions are totally valid for me:
DTO projections
Projection interfaces
Even more, in spring-data-examples appears both together (I know for sample purposes):
CustomerRepository.java
Thus:
When is mandatory use one over the other and why?
Exists a cost of performance one over the other?
Note in the Class-based Projections (DTOs) section says the following:
Another way of defining projections is by using value type DTOs (Data
Transfer Objects) that hold properties for the fields that are
supposed to be retrieved. These DTO types can be used in exactly the
same way projection interfaces are used, except that no proxying
happens and no nested projections can be applied.
Seems the advantages are: except that no proxying happens and no nested projections can be applied
DTO Approach
Pro
Simple and straigt forward
Con
It will result in more code as you have to create DTO class with constructor and getters/setters (unless you utilize Project Lombok to avoid boilerplate
code for DTOs).
No nested projections can be applied.
Projections
Pro
Less code as it uses only interfaces.
Nested projections can be applied
Dynamic projection allows you write one generic repository method to return
different subset of the attributes in entity object based on client's needs.
Con
Spring generates proxy at runtime
Query could return the entire entity object from database to Spring layer though a trimmed version (via Projection) is returned from Spring layer to client. I wasn't sure about this specific disadvantage, hoping someone to edit this answer if necessary.
If you need nested or dynamic projection, you probably want Projection approach rather than DTO approach.
Refer to official Spring doc for details.
I think that DTO was the first possible solution to work with a small set of data from the Entities. Today, many operations can also be made with projections, but you need to be careful with performance. If you see this Janssen's post Entities or DTOs – When should you use which projection? you will note that DTOs have better performance than projections for reading operations.
If you don't have the problem with performance, projections will be more graceful.
Is there a way to create the equivalent behavior provided by EclipseLink’s AdditionalCriteria annotation in JPA? That is, can we create additional filtering that is added to every query for a particular entity type? We can use EclipseLink, but we don’t want to be dependent on it.
Maybe, I'm a bit wrong, however, I'm trying to refactor my code right now via making use of #Converter annotation from JPA 2.1 to out-source the attribute-to-dbdata converting from the POJO class to a separate class. I'm mainly utilising a custom transformation for storing a kind of JSON blob into a database column. I have several cases, where I need to rely on the order of child entities, i.e., I store the set of utilised child entities in a many-to-many table to keep the relationship between the items and, furthermore, the order in a JSON array that just keeps the child entity identifiers (to keep the order). Then I have a resolving mechanism that keeps both sides always up-to-date, i.e., the db-data (string) will be converted to a (ordered) list of child entities (that are also stored in the DB and available via the set of child entities (many-to-many relationship).
So right now I'm wondering, whether I can handle this with a #Converter (AttributeConverter) implementation, since I'll require the set of child entities to resolve the db-data (string) to a (ordered) list of child entities (i.e. the "convertToEntityAttribute" method implementation)? Or whether I need to rely on my (a bit cumbersome) mechanism in the POJO class to convert between both sides?
AttributeConverter is for simple types only, not collections/maps, and as such provides a mapping between a java type and a database column. Some JPA implementations may allow mapping to multiple columns (I know the JPA implementation I use does, DataNucleus JPA, and some others may also allow it), but I doubt you'll get one that allows mapping to some other table entirely.
Better to look at your entity mappings and consider creating a dummy entity for this information somehow
I have a person object that has a list of addresses and in the mapping it is annotated to be fetched eagerly.
I have a criteriabuilder query where, say i want to fetch a person object but without fetching the address. how do i disable the eager feting in criteria query alone. is there a method?
The actual code is not this simple...this is just to give you an example.
Thanks in advance
It is normally better to use LAZY fetching in the mapping, and then fetch it eagerly when required using the JPQL "join fetch" option.
In JPA you could just select the data that you want from the entity, instead of the entire entity, then you could avoid the relationships. You could also use a constructor query to create shell instances (note these would not be managed).
A way to make an eager relationship lazy in a query is to use fetch groups. JPA does not support fetch groups, but some JPA providers such as EclipseLink do. In EclipseLink you can define a fetch group using the #FetchGroup annotation, or query hints.
I think it is possible. From OpenJPA documentation:
You can specify a default subclass fetch mode for an individual class with the metadata extension described in Section 9.1.1, “ Subclass Fetch Mode ”. Note, however, that you cannot "upgrade" the runtime fetch mode with your class setting. If the runtime fetch mode is none, no eager subclass data fetching will take place, regardless of your metadata setting.
This applies to the eager fetch mode metadata extension as well (see Section 9.2.1, “ Eager Fetch Mode”). You can use this extension to disable eager fetching on a field or to declare that a collection would rather use joins than parallel selects or vice versa
Section 9.2.1 here.