2011-11-02 18 views
12

Tôi đã viết một dự án cho Hibernate + MySQL. Bây giờ tôi đang chuyển nó đến Derby (vì một số lý do).HQL có tương đương với Restrictions.ilike (đối với trường hợp không khớp)?

Bây giờ tôi phát hiện ra rằng Derby phân biệt chữ hoa chữ thường khi sử dụng LIKE trong truy vấn. Điều này có thể được giải quyết bằng cách sử dụng Restrictions.ilike(...) trong Truy vấn tiêu chí ... nhưng tôi đã nhiều truy vấn HQL phức tạp HQL sử dụng điều đó. Có cách nào để có một chức năng tương tự như ilike trong HQL?

+0

Bạn đang nói ** như ** sẽ không hoạt động HQL trong cơ sở dữ liệu Derby? – ManuPK

+1

như * sẽ * hoạt động, nhưng trường hợp nhạy cảm – gotch4

Trả lời

15

Không có ilike chức năng tương đương trong HQL. Như Konstantin đã chỉ ra trong số suggestion của mình, lựa chọn tốt nhất của bạn là tune the database connection và đặt collation thành TERRITORY_BASED:SECONDARY, như được giải thích trong JIRA này: DERBY-1748: Global case insensitive setting.

Cân nhắc rằng tất cả các điểm cân bằng (=) và like sẽ không phân biệt chữ hoa chữ thường. Điều này có thể đi quá xa và không phù hợp với tình huống cụ thể của bạn.

Một cách khác để giải quyết vấn đề này là tạo chỉ mục dựa trên chức năng (nếu Derby hỗ trợ chúng) và điều chỉnh HQL của bạn để kết hợp likelower như thế này.

Query q = session.createQuery("... WHERE lower(entity.field) like ?)"); 
q.setString(0, '%' + variable.toLowerCase() + '%'); 

Nếu Derby không hỗ trợ FBI (tôi nghĩ là không), bạn cũng có thể tạo cột được kích hoạt có giá trị thấp hơn và lập chỉ mục chúng.

CẬP NHẬT Có vẻ như có thể xác định các cột có nguồn gốc/được tạo tự động, như được giải thích trong JIRA khác: JIRA-481: implement SQL generated columns.

+0

nhưng gotch4 thích giữ truy vấn HQL của mình –

+0

Anh ấy không có tùy chọn nào khác nếu anh ấy không muốn thay đổi collation kết nối. Và tôi hiểu anh ấy không muốn biến chúng thành các truy vấn tiêu chí. –

+1

Tôi hiểu anh ta - có thể là địa ngục của một refactoring và thử nghiệm –

Các vấn đề liên quan