Ebean - Zapytanie dynamiczne - Błąd niepoprawnego licznika przygotowanych instrukcji

Question

Mam nadzieję, że ktoś z większą wiedzą na temat Ebean niż ja może mi pomóc z nieprawidłowym problemem. Zajmuję się teraz rozwiązywaniem problemów.

Środowisko:

• Java 1.7.0_17
• MySQL 5.5
• play Framework 2.1.1 (jednak mam zmodernizowane grać 2.2.1 i problem ten nadal istnieje)

Moim głównym problemem jest to, że dostaję naprzemiennie SQLExceptions po ponownym uruchomieniu Play, wszystko związane z zbyt dużą lub zbyt małą ilością parametrów w przygotowywanej instrukcji, którą tworzy Ebean. Zestaw danych A działa przez połowę czasu, gdy zestaw danych B ulegnie awarii, ale po ponownym uruchomieniu Play zestaw danych B działa, gdy zestaw danych A nie działa.

Buduję obiekt kwerendy Ebean dynamicznie na podstawie obiektów zestawu filtrów, które napisałem, przekazanych do funkcji. Kwerenda Ebean znajduje wszystkie obiekty, które spełniają określone wymagania każdego Filtra.

Funkcja jest podobna do:

private List<Contact> contacts getContacts(Set<Filter> filters) { 
    Query<Contact> query = Contact.find; 
    for (Filter filter : filters) { 
     filter.apply(query); 
    } 
    List<Contact> contacts = query.findList(); 
} 

Przykładem Filtr:

public void apply(Query<Contact> query) { 
    query.where().in("tags", getTags()); 
} 

Po pierwsze, jest to rodzaj budynku zapytań obsługiwane Ebean? Uważam jednak, że tak jest przez większość czasu, jednak mam problemy z uruchomieniem funkcji "getContacts" kilkaset razy z pewnymi danymi, ale tylko czasami ...

Więc trzymaj się mnie, ponieważ ten problem jest bardzo mylące. Zamierzam również prześwietlić większość szczegółów dotyczących danych, ale jeśli chcesz/potrzebujesz więcej informacji, zapytaj.

zestawu danych kwerendy i wyjątek A w:

select distinct t0.contact_id c0, t0.contact_uuid c1, t0.bounce c2 
from contact t0 
join email_record u1 on u1.contact_id = t0.contact_id 
join contact_tag u2z_ on u2z_.contact_id = t0.contact_id 
join tag u2 on u2.tag_id = u2z_.tag_id 
where u1.status = ? and t0.unit_id = ? and u2.tag_id in (?,?,?) and t0.unit_id in (?) and t0.campaign_id in (?,?,?,?,?,?,?,?,?,?,?,?) 

[PersistenceException: Error with property[19] dt[4]data[1464][java.lang.Integer]] 
Caused by: java.sql.SQLException: Parameter index out of range (19 > number of parameters, which is 18). 

Następnie po play restartu, zbiór danych kwerendy i wyjątek B:

[PersistenceException: Query threw SQLException:No value specified for parameter 19 Bind values:[SENT, 1290, 8988, 13032, 13052, 1290, 96, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 222] Query was: select distinct t0.contact_id c0, t0.contact_uuid c1, t0.bounce c2 from contact t0 join email_record u1 on u1.contact_id = t0.contact_id join contact_tag u2z_ on u2z_.contact_id = t0.contact_id join tag u2 on u2.tag_id = u2z_.tag_id where u1.status = ? and t0.unit_id = ? and u2.tag_id in (?,?) and t0.unit_id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) and t0.campaign_id in (?,?,?,?,?,?,?,?,?,?,?,?) ] 

czuję, że najbardziej kłopotliwy kawałek o to jak to przełącza niezawodnie 100% czasu tam iz powrotem po restarcie.

Czy ktoś kiedykolwiek widział coś takiego wcześniej? Aby dodać do zamieszania, dodatkowo robi się coś bardzo podobnego (na różnych zestawach danych) w naszym środowisku produkcyjnym, ale nie mogę tego odtworzyć na komputerach do projektowania lub testowania, nawet po zrzuceniu bazy danych i załadowaniu jej lokalnie. Problem opisany powyżej jest jednak powtarzalny wszędzie.

Answer 1

Na liście tablicowej() znajduje się wartość pusta. jeśli debugujesz kod, zobaczysz wartość null w tablicy tagów.

Answer 2

Widziałem coś podobnego (na DB2) przy użyciu gotowych instrukcji. Właściwości działały tylko dla liczby parametrów, które były wykonywane przez pierwszą instrukcję. Została uruchomiona tylko liczba parametrów, z którymi był wywoływany po raz pierwszy. Prawdopodobnie odłożył bufor na parametry - uważam, że działał tak, jak nie istniały dodatkowe parametry.

Jeśli pierwsze połączenie ma wystarczającą liczbę parametrów, wszystko będzie w porządku, dopóki nie uzyskasz więcej niż tę liczbę parametrów. Ale następne uruchomienie może natychmiast zakończyć się niepowodzeniem, jeśli pierwsze zapytanie ma tylko jeden parametr, a następne wywołanie ma więcej niż jeden.

Sprawdź, czy działa z regularnym wyciągiem, a nie z przygotowanym wyciągiem. Jeśli tak, to podejmij błąd w przygotowanych instrukcjach obsługi dla zmiennych liczb parametrów.