QueryDSL не находит правильные типы параметров - PullRequest
Новая
       8

QueryDSL не находит правильные типы параметров

0 голосов
/ 28 мая 2018

Я получаю исключение при выполнении JPAQuery, так как я обновил QueryDsl до версии 4.2.1.До того, как я работал на 3.7.4, где он работал нормально.

Я изолировал проблему с этой сущностью: 

@Entity(name = "TEST")
public class Test implements Serializable {

    @Id
    @Column(name = "TEST_ID", nullable = false)
    private Long id;

    @Column(name = "TEST_NAME", nullable = false)
    private String name;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

Я написал тест JUnit, который вызывает этот метод: 

public void test() {
    QTest qTest= QTest.test;
    JPAQuery<Test> query = getJpaQueryFactory().selectFrom(qTest);
    query.where(qTest.name.startsWith("test"));
    List<Test> tests = query.fetch();
}

Это работает нормально и возвращает то, что должно.Однако когда я меняю порядок в методе StringExpression.startsWith, я получаю странное исключение. 

public void test() {
    QTest qTest= QTest.test;
    JPAQuery<Test> query = getJpaQueryFactory().selectFrom(qTest);
    StringExpression longName = Expressions.asString("test01");
    query.where(longName.startsWith(qTest.name));
    List<Test> tests = query.fetch();
}

В методе fetch () я получаю: 

IllegalArgumentException : You have attempted to set a value of type class java.lang.String
for parameter 1 with expected type of class java.lang.Boolean from query string
select test from TEST test where ?1 like concat(test.name,?2) escape '!'.

Я использовалотладчик, чтобы копаться в коде querydsl, и, как утверждает Исключение, построитель запросов ожидает логическое значение для параметра 1, но я понятия не имею, почему.

Кроме того, он помещает «%» в качестве параметра 1, а мою строку поиска «test01» в качестве параметра 2. Хотя все должно быть наоборот.

Кто-нибудь видел это раньше?Мне кажется, это ошибка в QueryDSL 4.2.1, но, возможно, с моей стороны есть недосмотр.

Заранее спасибо за любую помощь!

...