Do you need to render Asciidoc documents with Spring MVC? If so, read Rendering Asciidoc Documents with Spring MVC!

Spring Data JPA Tutorial Part Five: Querydsl

Easy way sign

The fourth part of my Spring Data JPA tutorial described how you can implement more advanced queries with the JPA criteria API. As you might remember, the goal of the previous part of this tutorial was to implement a search function which returns only such persons whose last name begins with the given search term. This blog entry will describe how you use Querydsl and Spring Data JPA for the same purpose.

Lets get to work and see how you can fulfill this requirement.

Required Steps

The steps needed to implement the given requirement are following:

  • Configuring the Maven integration of QueryDSL
  • Generating the Querydsl query type
  • Implementing the predicate builder class
  • Extending the repository to support Querydsl predicates
  • Using the created repository

Each of these steps is described with more details in following Sections.

Configuring the Maven Integration of Querydsl

The configuration of the maven integration of Querydsl consists two smaller phases:

First, you need to add the Querydsl dependencies to your pom.xml file. The needed dependencies are:

  • Querydsl core which provides the core functions of Querydsl.
  • Querydsl APT integration which provides support for the APT based code generation.
  • Querydsl JPA which provides support for the JPA annotations.

The relevant part of the pom.xml is given in following:

<dependency>
	<groupId>com.mysema.querydsl</groupId>
	<artifactId>querydsl-core</artifactId>
	<version>2.3.2</version>
</dependency>

<dependency>
	<groupId>com.mysema.querydsl</groupId>
	<artifactId>querydsl-apt</artifactId>
	<version>2.3.2</version>
</dependency>

<dependency>
	<groupId>com.mysema.querydsl</groupId>
	<artifactId>querydsl-jpa</artifactId>
	<version>2.3.2</version>
</dependency>

Querydsl uses the Annotation Processing Tool of Java 6 for code generation. Thus, the next phase is to add the the configuration of the Maven APT plugin to the plugins section of your pom.xml file. The relevant part of the pom.xml looks following:

<plugin>
	<groupId>com.mysema.maven</groupId>
    <artifactId>maven-apt-plugin</artifactId>
    <version>1.0.2</version>
    <executions>
    	<execution>
        	<phase>generate-sources</phase>
            <goals>
            	<goal>process</goal>
            </goals>
            <configuration>
				<!-- Specifies the directory in which the query types are generated -->
            	<outputDirectory>target/generated-sources</outputDirectory>
				<!-- States that the APT code generator should look for JPA annotations -->
                <processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
            </configuration>
		</execution>
	</executions>
</plugin>

Generating the Querydsl Query Type

The next step is to generate the Querydsl query type which is used to construct queries with Querydsl. All you have to do is to build your project and the query type is generated under the target/generated-sources directory. If you open this directory, you should notice that the query type class is created in the same package than the Person class. Since the name of the model class is called Person, the name of the Querydsl query type is QPerson.

NOTE: Remember to add the target/generated-sources directory as a source directory for your project before moving forward (Check the documentation of your IDE for more details about this).

Implementing the Predicate Builder Class

In my previous part of this tutorial, I used a builder class with static methods to build the actual Specification instances. I am following the same principle when building the Querydsl predicates by using the generated QPerson query type. The source code of my predicate builder class is given in following:

import com.mysema.query.types.Predicate;
import net.petrikainulainen.spring.datajpa.model.QPerson;

/**
 * A class which is used to create Querydsl predicates.
 * @author Petri Kainulainen
 */
public class PersonPredicates {

    public static Predicate lastNameIsLike(final String searchTerm) {
        QPerson person = QPerson.person;
        return person.lastName.startsWithIgnoreCase(searchTerm);
    }
}

At first I had no idea how my builder class could be tested, because the information about unit testing Querydsl is kind of hard to find. Luckily I was able to find a google groups thread, which discusses about this matter. After reading that thread I decided that testing the return value of toString() method of the created predicate is enough because this scenario is quite simple. The source code of my unit test is given in following:

import com.mysema.query.types.Predicate;
import org.junit.Test;

public class PersonPredicatesTest {
    
    private static final String SEARCH_TERM = "Foo";
    private static final String EXPECTED_PREDICATE_STRING = "startsWithIgnoreCase(person.lastName,Foo)";

    @Test
    public void lastNameLike() {
        Predicate predicate = PersonPredicates.lastNameIsLike(SEARCH_TERM);
        String predicateAsString = predicate.toString();
        assertEquals(EXPECTED_PREDICATE_STRING, predicateAsString);
    }
}

If you have read my blog entry about using the JPA criteria API with Spring Data JPA, you might remember that the unit test of my lastNameLike() method was rather long and looked a bit messy. The problem is that mocking the JPA criteria API becomes a lot more complex when you are building more complex queries. This means that writing pure unit tests for your code takes longer and longer.

My unit test for the Querydsl implementation of the same method is the exact opposite. It is short and looks quite clean. And more importantly, it is much faster to write. This means that you can concentrate on adding value to your application instead of verifying its behavior.

Extending the Repository to Support Querydsl Predicates

Extending the repository to support Querydsl predicates is quite straightforward process. All you have to do is to extend the QueryDslPredicateExecutor interface. This gives you access to findAll(Predicate predicate) method. This returns all entities fulfilling the search conditions which are specified by the predicate. The source code of my PersonRepository interface is given in following:

import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.querydsl.QueryDslPredicateExecutor;

/**
 * Specifies methods used to obtain and modify person related information
 * which is stored in the database.
 * @author Petri Kainulainen
 */
public interface PersonRepository extends JpaRepository<Person, Long>, QueryDslPredicateExecutor<Person> {

}

Using the Created Repository

The last step is to implement the service class which uses the created predicate builder and the repository. The PersonService interface contains a method search(String searchTerm) which returns a list of persons matching with the given search term. The relevant part of the PersonService interface is given in following:

/**
 * Declares methods used to obtain and modify person information.
 * @author Petri Kainulainen
 */
public interface PersonService {

    /**
     * Searches persons by using the given search term as a parameter.
     * @param searchTerm
     * @return  A list of persons whose last name begins with the given search term. If no persons is found, this method
     *          returns an empty list. This search is case insensitive.
     */
    public List<Person> search(String searchTerm);
}

Implementing the search method is pretty straightforward. My implementation uses the PersonPredicates class to obtain the Querydsl predicate and passes the received predicate forward to the PersonRepository. Since the findAll() method returns Iterable instead of List, I had to add an extra method which converts the returned Iterable into a List. The source code of the search(String searchTerm) method is given in following:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import javax.annotation.Resource;

import static net.petrikainulainen.spring.datajpa.repository.PersonPredicates.lastNameIsLike;

/**
 * This implementation of the PersonService interface communicates with
 * the database by using a Spring Data JPA repository.
 * @author Petri Kainulainen
 */
@Service
public class RepositoryPersonService implements PersonService {
    
    private static final Logger LOGGER = LoggerFactory.getLogger(RepositoryPersonService.class);
    
    @Resource
    private PersonRepository personRepository;

    @Transactional(readOnly = true)
    @Override
    public List<Person> search(String searchTerm) {
        LOGGER.debug("Searching persons with search term: " + searchTerm);

        //Passes the specification created by PersonPredicates class to the repository.
        Iterable<Person> persons = personRepository.findAll(lastNameIsLike(searchTerm));
        return constructList(persons);
    }
    
    private List<Person> constructList(Iterable<Person> persons) {
        List<Person> list = new ArrayList<Person>();
        for (Person person: persons) {
            list.add(person);
        }
        return list;
    }
}

The same architectural remarks which I made in the previous part of my Spring Data JPA tutorial are also valid in this case. However, the end result looks pretty clean and simple. The only thing which is left, is to write a unit test for the search method. The source code of the unit test is given in following:

import com.mysema.query.types.Predicate;
import org.junit.Before;
import org.junit.Test;

import static junit.framework.Assert.assertEquals;
import static org.mockito.Mockito.*;

public class RepositoryPersonServiceTest {

    private static final String SEARCH_TERM = "foo";
    
    private RepositoryPersonService personService;

    private PersonRepository personRepositoryMock;

    @Before
    public void setUp() {
        personService = new RepositoryPersonService();

        personRepositoryMock = mock(PersonRepository.class);
        personService.setPersonRepository(personRepositoryMock);
    }

    @Test
    public void search() {
        List<Person> expected = new ArrayList<Person>();
        when(personRepositoryMock.findAll(any(Predicate.class))).thenReturn(expected);
        
        List<Person> actual = personService.search(SEARCH_TERM);
        
        verify(personRepositoryMock, times(1)).findAll(any(Predicate.class));
        verifyNoMoreInteractions(personRepositoryMock);
        
        assertEquals(expected, actual);
    }
}

What is Next?

I have now demonstrated to you how you can build advanced queries with Spring Data JPA and Querydsl. As always, the example application described in this blog entry is available at Github. The next part of my tutorial describes the sorting capabilities of Spring Data JPA.

If you want to learn more about Spring Data JPA, you should read all parts of my Spring Data JPA tutorial.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

48 comments… add one

  • hi,petri,why in code didn’t find QPerson class

    Reply
    • Hi Neo,

      Did you remember to generate the Querydsl query type and add the target/generated-sources directory as a source directory for your project?

      Reply
    • Hi neo, in the root project right click, in the maven option click in maven-generate-sources after process go to the folder target/generated-sources/your package, in this folder you find the class QPerson.java…

      Greetings.

      Petri, Thanks you, is the best of the best in tutorials, You helped me a lot.

      PD: Sorry for my bad english… Im from Colombia… xD

      Reply
      • Manolosoft,

        Great to hear that I could help you out.

        Reply
  • Yes, got it, but don’t understand why. Thank you very much!

    Reply
  • Hi Petry, nice tutorial!

    I have one question concerning this aproach:

    Suppose I declared some methods that will be parsed into queries by Spring Data JPA in the interface that extends both JpaRepository and QueryDslPredicateExecutor (PersonRepository). “findByFirstname” for instance.

    In the service class (RepositoryPersonService) I implement the complex queries using QueryDsl.

    In the classes that use the service I want to call the simple methods (parsed by JPA) and also the complex methods (QueryDsl). For that I’d have to inject both repositories in my classes? One of type “PersonRepository” and other of type “PersonService”.

    I don’t think it’s a good idea to have two injections that has the same objective. A solution would be copping every relevant method signature to the “PersonService” interface, and implement then at the “RepositoryPersonService” class, making use of an injected “PersonRepository”. But it seems to me too much ctrl+c ctrl+v. Do you know a better approch?

    Reply
    • Hi Tiago,

      Thank you for your comment. You made a good point concerning the problems related to a situation where the PersonRepository is injected to the RepositoryPersonService class. It is indeed true that some methods of the PersonRepositoryService class are just delegating the method call forward to person repository.

      This sucks, but I still prefer this approach because this way I can use the service layer as transaction boundary and provide a decent separation between the controller “logic” and the application “logic”.

      Adam Biem has some interesting ideas concerning the architecture of Java EE applications. He actually provides a solution for the problem you mentioned. Unfortunately, you cannot use his solution if you are using Spring MVC. If you are interested, you should definitely check out his blog: http://www.adam-bien.com/roller/abien/

      Reply
  • Hi Petri,
    thanks for your tutorials. I have a question regarding querying with querydsl. Is it possible to create a predicate that contains (multiple) Joins?

    I have a many-to-many relationship with a link table. That link table contains an additional field and is also represented by a Entity class.

    I can create findBy methods that span tables. However my actual comparison is not just String or numbers but an actual function call, eg in SQL: where myFunction(:param1, :param2) = true.

    Is his possible?

    Reply
    • Hi Thomas.

      Is your question how to create multiple joins in Spring Data with Querydsl or directly in a Querydsl query?

      You can also use custom expressions in Querydsl, but you need to register your functions in some way on the JPA provider level.

      Br,
      Timo Westkämper

      Reply
  • Hi Petri,

    I’m using Eclipse 3.7 with m2e 1.1. I tried loading your code and it complains that the maven-apt-plugin lifecycle is not covered. I know I can manually generate the sources using maven generate-sources everytime something changes, but that is a bit of a nuissance. I tried instaling the m2e-querydsl plugin (https://github.com/ilx/m2e-querydsl) and that removed the error in the pom, but did nothing to generate the sources in the outputDirectory nor add the generated-sources to the Deployment Assembly.

    Are you aware of a functional m2e connector that works with querydsl? I am hoping that you encountered some while writing your blog and/or book.

    Thanks,

    Eric

    Reply
    • Hi Eric,

      Unfortunately the only advice that I was able to found was to generate the Querydsl query types by running the mvn generate-sources command at command prompt every time when something changes. This is indeed really irritating for Eclipse users and this is one drawback of Querydsl (at least at the moment).

      Reply
  • Hi Petri,

    After a lot of stuggling and searching, I did find the following. Upgrading to m2e 1.2 and using the following in my pom.xml worked to compile your code. Also enables auto-regen of querydsl classes:

    
    <plugin>
        <!-- Requires mysema m2e plugin (http://ilx.github.com/m2e-querydsl/repository/0.0.5/) -->
        <groupId>com.mysema.maven</groupId>
        <artifactId>maven-apt-plugin</artifactId>
        <version>1.0.4</version>
        <executions>
            <execution>
                <goals>
                    <goal>process</goal>
                </goals>
                <configuration>
                    <logOnlyOnError>true</logOnlyOnError>
                    <outputDirectory>target/generated-sources/apt</outputDirectory>
                    <processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
                </configuration>
            </execution>
        </executions>
        <dependencies>
            <dependency>
                <groupId>com.mysema.querydsl</groupId>
                <artifactId>querydsl-apt</artifactId>
                <version>${querydsl.version}</version>
            </dependency>
            <dependency>
                <groupId>com.mysema.querydsl</groupId>
                <artifactId>querydsl-jpa</artifactId>
                <classifier>apt</classifier>
                <version>${querydsl.version}</version>
            </dependency>
        </dependencies>
    </plugin>
    <!-- right now this seems needed -->
    <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <executions>
            <execution>
                <id>add-source</id>
                <phase>generate-sources</phase>
                <goals>
                    <goal>add-source</goal>
                </goals>
                <configuration>
                    <sources>
                        <source>target/generated-sources/apt</source>
                    </sources>
                </configuration>
            </execution>
        </executions>
    </plugin>
    
    

    This also required the m2e connector for build-helper-maven-plugin which was easily found via the m2e catalog.

    According to the querydsl plugin site (https://github.com/mysema/maven-apt-plugin/issues/9), the apt plugin is supposed to work without the querydsl connector/plugin, but I have been unable to get it to work without that plugin.

    Hopefully this info can help you or someone else in the future.

    Thanks,

    Eric

    Reply
    • Wow, that is valuable information. Thank you so much for posting it to my blog.

      Reply
  • Hi Petri,
    Can you suggest on how to construct query by joining 2 tables?
    Thanks,
    Hari

    Reply
    • Hi Hari,

      If you are using the Spring Data JPA, you have two options:

      If your repository interface extends the QueryDslPredicateExecutor interface, you can use the any() method with collection path. More details about this approach is found from this Stack Overflow question.

      If you have created a custom repository implementation that extends the QueryDslRepositorySupport class (details here), you can use the from() method to get a JPQLQuery object and use the methods provided by it.

      I hope that this answered to your question.

      Reply
  • Petri,
    Very nice tutorials.
    As someone just starting to use SpringData and QueryDSL, this tutorial is very helpful.

    That said, in my Service impl class, this is not working for me:

    Iterable persons = personRepository.findAll(lastNameIsLike(searchTerm));

    Instead, I am having to do this:

    Iterable persons = personRepository.findAll(PersonPredicates.lastNameIsLike(searchTerm));

    to be able to use the static method lastNameIsLike in the PersonPredicates class.

    Not sure why – I must be making some mistake…

    Thanks again.

    Reply
    • Hi,

      Good to hear that this blog entry was useful to you. About your problem, are you having a compilation error or a runtime error?

      Reply
  • Hi,

    good tutorial,
    I am looking at passing multiple search terms (multiple predicates) which is fine within java as I can use BooleanExpression and or etc… methods to build a Predicate to pass to a findAll method.

    Where I’m failing to find info on is how to express this on a REST URL. I don’t want to use findByXxxxAndYyyy as the number of properties is large enough to create a lot of these methods.

    Any advice or pointers much appreciated

    Regards
    Sean

    Reply
    • Are you using using Spring Data REST or a “normal” Spring MVC controller?

      If you are using a “normal” Spring MVC controller, you can create a request handler method that handles GET requests and specify the search conditions as optional request attributes (Use @RequestParam annotation and set the value of its required property to false.

      I have not personally tried Spring Data REST but I took a quick look at it and it seems that it can be used to provide automatic CRUD operations as a REST API. It has a support for search as well, but it seems that you have to create your queries by using the query generation by method name strategy. Like you said, this means that you have to create multiple repository methods if you have many optional search parameters. If this is not an option, you can always create a “normal” Spring MVC controller and use the technique described above.

      Reply
      • Thanks
        I’m using spring MVC controller at the moment, but I’m trying to ensure my URL is such that it aligns with spring data rest, so I’m trying to see what other people think. I’ll do a bit more digging on Spring data REST and post back here.

        Reply
  • Hi Petri,

    I’m now using your book, it’s quite an easy ride into Spring Data JPA, thank you for that.

    My only road block for now is that I have a multi modules Maven project and that maven-apt-plugin configuration gives an error with a basedir not being found.

    [ERROR] execute error
    java.lang.IllegalStateException: basedir /home/stephane/dev/java/projects/learnintouch/src/main/java does not exist

    I guess there may be a property to set in there, specifying the input directory.

    But I can’t yet find that information.

    Kind Regards,

    Reply
    • Hi Stephane,

      Have you configured the Maven APT plugin in the POM file of the module which contains your domain model classes?

      Reply
  • Hello Petri,

    Being new to Spring (and to java in general), I really enjoy your tutorials, this really help me get forward and learn new skills directly useable!
    I tired this one and I had at first tried the querydsl version 3.1.1, however I always got a nice stack:

    java.lang.NoSuchMethodError: com.mysema.query.jpa.impl.JPAQuery.from([Lcom/mysema/query/types/EntityPath;)Lcom/mysema/query/jpa/JPQLQueryBase;
    ….
    downgrading querydsl to 2.3.2 did the trick.

    I tried reading their documentation for v3.1.1, but I could not find anything that would point me into the correct direction?
    What should be changed in the above example to have it work with querydsl 3.1.1?

    Thanks a lot in advance ;)
    Francois

    Reply
  • Hi,

    Thanks for the great tutorial. Is there any chance I can get this to work without maven? I have all the relevant queryDSL jars in my classpath. How do I go about generating the QueryDSL code (QPerson etc.)?

    Reply
  • Petri, thanks for these great tutorials!
    Actually I’m finding hard to use Querydsl extensively. Apart of NullPointerExceptions with some predicate, which could be my fault with packages’ version, I had to switch to Jpql because it’s not possible to specify eager load of properties inside predicate. I should do an extra call after querying and this would be inefficient.
    Are you having similar issues?

    Reply
    • Hi Pietro,

      I haven’t personally experienced any NPEs but I have to admit that I haven’t used Querydsl for creating complicated queries. The project in which I work now uses criteria queries and I use them too because I want to keep the code base consistent.

      I think that it might be a good idea to create a bug report to Github.

      Have you considered using joins or subqueries for fetching the required properties of an entity?

      Reply
  • It seems the problem was already raised, and waiting for a “higher level” solution: http://forum.spring.io/forum/spring-projects/data/108202-custom-fetch-groups-with-spring-data-jpa-possible
    I’ll explore the subquery solution, but it would involve a sub select, don’t know if suits my needs. Anyway, thanks for your suggestions.

    Reply
    • You are welcome.

      JPA 2.1 adds support for both named and unnamed entity graphs. I assume that it is just a matter of time before Spring Data JPA supports these features as well.

      Reply
  • Hi Petri, I found the reason for my NPE when building predicates…
    Querydsl by default initializes only direct properties, and leaves to the user the choice to init nested ones.
    So, by default, if QPerson person is your Query type, person.address.city throws an NPE.
    Solutions are to annotate entities, but I preferred the “create on demand” alternative, which is explained here:
    https://github.com/mysema/querydsl/issues/134

    Shortly, adding

    <querydsl.entityAccessors>true</querydsl.entityAccessors>

    to your Maven APT configuration, will replace direct fields with accessors (and will screw your existing code :P)

    Bye

    Reply
    • Great! Thanks for dropping a note about the solution!

      Reply
  • Hi Petri;

    I want to write a join like ‘Select * from A a left join B b on a.MEDIA_ID = b.ID’,
    how to achieve this in Spring Data JPA.

    Thanks in advance.

    Reply
    • If the A class has a field called b and you have mapped your domain model correctly, you can create the query by adding the following query method to your repository interface:

      
      @Query("Select a From A a LEFT JOIN FETCH a.b")
      public List<A> getA();
      
      
      Reply
      • thanks Petri,
        How to make association?

        I have two table TableA and TableB. Table A has column media_Id which is the primary key of Table B. and Table B has ‘description’ for a particular media_Id.

        Now i want to get the content of Table A with description added in the for every record. I don’ t know what i need to write in My entities class for association.
        But when as kept

        @OneToOne(targetEntity=B.class)
        @JoinColumn(name=’media_Id’)
        private B b;

        I am getting all the content of Table B in findAll() query.

        But what i want is only description column from table b not entire row of table B. Hope you understand…

        Wating for your reply. Happy weekend….

        Reply
        • I think that your best option is to return a DTO instead of an entity. This way you can select the fields which you want to return. Take a look at this comment made by Dominik Werner. It should help you to get started.

          If you have further questions about this, don’t hesitate to ask!

          Reply
  • Hi Petri!

    I have read your Spring Data book and I’ve used your implementation example in order to create some QueryDsl Predicates, using them by extending in my repositories QueryDslPredicateExecutor interface.

    Now I’ve a little bit complicated situation. My EntityA has a ManyToMany relationship with EntityB

    EntityA{

    @ManyToMany
    Set entitiesB;
    }

    EntityB{
    String name;
    }

    I have to filter EntityA based on the fact that EntityA have almost one EntityB which contained name string I’m looking for. For example I want to see all EntityA which have almost one EntityB with name like ‘ISO’.

    Here is my JPA query:
    select eA from EntityA eA join eA.entitiesB eB where eB.name in (:names) group by eA

    This query works, I dont know if it is very optimized.. but it works.

    I cannot realize how can I translate this in a predicate, that is required by findAll method in my repository.. I have create a JpaQuery object, but Jpa repositories want Predicates..

    Thank you for any suggestion!

    Reply
    • Hi,

      It would be useful to see the SQL query which is created from your JPQL query. Could you add it here? The reason why I am asking this is that I am wondering what column is used in the group by clause.

      I haven’t tested this predicate builder class in any way but here is what I have so far:

      
      public class EntityAPredicates {
          public static Predicate entityBNameIn(final Collection<String> names) {
              return QEntityA.entityA.entitiesB.any().name.in(names); 
          }
      }
      
      
      Reply
      • This is the query. I’ve not changed real name of entities this time..

        So the real query is:

        select n from Norma n join n.entiNormazione e where e.sigla in (:sigle) group by n

        that gives:

        select
        entinormaz0_.norma as norma6_1_,
        entinormaz0_.enti_normazione as enti2_7_1_,
        entenormaz1_.id as id2_0_,
        entenormaz1_.created_by as created2_2_0_,
        entenormaz1_.created_date as created3_2_0_,
        entenormaz1_.last_modified_by as last4_2_0_,
        entenormaz1_.last_modified_date as last5_2_0_,
        entenormaz1_.version as version2_0_,
        entenormaz1_.sigla as sigla2_0_
        from
        norma_enti_normazione entinormaz0_
        inner join
        ente_normazione entenormaz1_
        on entinormaz0_.enti_normazione=entenormaz1_.id
        where
        entinormaz0_.norma=?
        order by
        entenormaz1_.sigla

        Thanks for now, I’ll let you know if it is correct.

        Thank you very much for your reply.
        Marco

        Reply
      • Thank you very much, it works!

        I had not really thought about this solution.

        now the generated query is:

        select
        norma0_.id as id6_,
        norma0_.created_by as created2_6_,
        norma0_.created_date as created3_6_,
        norma0_.last_modified_by as last4_6_,
        norma0_.last_modified_date as last5_6_,
        norma0_.version as version6_,
        norma0_.aggiornamento as aggiorna7_6_,
        norma0_.anno as anno6_,
        norma0_.descrizione as descrizi9_6_,
        norma0_.numero as numero6_,
        norma0_.titolo as titolo6_
        from
        norma norma0_
        where
        (
        exists (
        select
        1
        from
        ente_normazione entenormaz1_
        where
        (
        entenormaz1_.id in (
        select
        entinormaz2_.enti_normazione
        from
        norma_enti_normazione entinormaz2_
        where
        norma0_.id=entinormaz2_.norma
        )
        )
        and entenormaz1_.sigla=?
        )
        )
        and (
        exists (
        select
        1
        from
        ente_normazione entenormaz3_
        where
        (
        entenormaz3_.id in (
        select
        entinormaz4_.enti_normazione
        from
        norma_enti_normazione entinormaz4_
        where
        norma0_.id=entinormaz4_.norma
        )
        )
        and entenormaz3_.sigla=?
        )
        )
        order by
        norma0_.numero asc limit ?

        Reply
  • Thank you for the great tutorials you have provided, they really help clarify issues. I like the way you use QueryDSL, but I wonder if you have tried to use it with Gradle? As far as I can tell, based upon searching, it should work but haven’t actually seen a working implementation.

    Reply
    • Thank you for your kind words. I really appreciate them!

      I haven’t tried Gradle yet. However, I managed to find this Stack Overflow question which might help you out.

      Reply
    • It seems to be working fine now. Perhaps it was a temporary problem.

      Reply
  • Hello, I was going through your amazing tutorials to learn Spring Data JPA. However, I am stuck with one issue i.e. I see reference for a class “net.petrikainulainen.spring.datajpa.model.QPerson”. However, This class is no where to be found in the source code shared by you. Now this is giving the compile error in my eclipse.
    Kindly let me know if I am missing something.

    Reply
    • That class is generated by the Maven APT plugin. Its process goal is invoked at the generate-sources Maven lifecycle phase. If you cannot get this work in Eclipse, you should try the configuration explained in this comment.

      Reply
  • Thanks!!! great post i have the problem with “NoSuchMethodError: com.mysema.query.jpa.JPQLQuery.from” but after change the QUERYDSL dependecy for the versión 2.3.2 my proyect works!

    com.mysema.querydsl
    querydsl-apt
    2.3.2

    com.mysema.querydsl
    querydsl-jpa
    2.3.2

    greetings from chile!

    Reply
    • The example application of this blog post uses rather old versions of Spring Data JPA and Querydsl. You might want to update both dependencies to the latest versions (Spring Data JPA 1.6.0.RELEASE should support Querydsl 3.3.3).

      Anyway, It is good to hear that you were able to solve your problem!

      Reply

Leave a Comment