SODA запрос для JODA DateTime в DB4O

Question

Я использую db4o и JODA и получил проблему с хранением/получением объектов DateTime. По крайней мере, я думаю, что это была проблема.

Мой datamodell выглядит так же, как это:

DataFile.class 
    enum FileType {...} 
    further attributes... (primitve data types) 

Product.class extends DataFile.class 
    enum ProductType {...} 
    further attributes... (primitve data types) 

KindOfProduct.class extends Product.class 
    DateTime time 
    further attributes... (primitve data types) 

i'am создания объектов KindOfProduct и хранить их в Встраиваемая СУБД. Для запроса этих объектов я использую SODA и получил DateTimeComparison.class, который реализует оценку. Запрос для полей, отличных от DateTime, работает нормально, но запрос DateTime не выполняется. Странно, что метод оценки вызывается только один раз, независимо от того, сколько объектов хранится в моей базе данных. Метод включения candidate вызывается с true, но кандидат не включен в ObjectSet. Таким образом, кажется, что ошибка встречается где-то , а db4o выходит, не выбрасывая исключение (что является известной проблемой для оценки запросов SODA, по внешнему виду). Выполнение запроса с помощью плагина Enterprise Manager Enterprise для Eclipse не удается. Я получаю сообщение об ошибке «Не отображать результаты» .

Я уверен, что я правильно реализовал интерфейс Evaluation (я сделал аналогичный для другой тип данных, чем DateTime, и он отлично работает). Я не думаю, что мне нужно реализовать объект TypeHandler для хранения объектов DateTime, поскольку не нужно было делать это в другом проекте (я использовал собственные запросы в этом случае, но я думаю, что это не так) ,

Итак, любые идеи о том, как искать? Любые известные подводные камни?

EDIT: код моего класса оценки

import org.joda.time.DateTime; 

import com.db4o.query.Candidate; 
import com.db4o.query.Evaluation; 

public class DateTimeComparison implements Evaluation { 

protected enum Operator { 

    GREATER, SMALLER, EQUAL 

} 

private Operator operator = null; 
private DateTime value = null; 

public DateTimeComparison(String operator, DateTime value) { 

    if (operator.equals(">")) { 
     this.operator = Operator.GREATER; 
    } else { 
     if (operator.equals("<")) { 
      this.operator = Operator.SMALLER; 
     } else { 
      this.operator = Operator.EQUAL; 
     } 
    } 
    this.value = value; 

} 

public void evaluate(Candidate candidate) { 

    DateTime dateTime = (DateTime) candidate.getObject(); 

    boolean match = false; 
    switch (operator) { 
    case GREATER: 
     match = dateTime.compareTo(value) > 0; 
     break; 
    case SMALLER: 
     match = dateTime.compareTo(value) < 0; 
     break; 
    case EQUAL: 
     match = dateTime.compareTo(value) == 0; 
     break; 
    } 
    candidate.include(match); 
    System.out.println(match); 

} 

} 

Answer 1

Вы можете показать свой код оценка/класс?

В противном случае:

Обратите внимание, что оценка будет «медленным», потому что не может использовать индексы. В больших наборах данных это становится проблемой.

Самый надежный, но уродливый способ избежать проблем, он хранит обычную дату Java в сохраненном объекте. И переведите поле Date в JotaTime DateTime в getters/seters. И для запроса тоже.

К описанию типа: в теории вы можете заставить его работать. Простой обработчик типа, который просто хранит DateTime, вероятно, не так уж тяжело. Но для расширенных функций, таких как указатели типа handlers, являются кошмаром (без документа, нужно бросать материал во внутренние структуры данных и т. Д.).

Answer 2

При попытке создать тестовый пример, я нашел свою ошибку. Проблема не в оценке, а в том, как я строю свои ограничения для запроса. Я работаю над тем, как динамически строить эти ограничения, читая их из txt-файла. Я не заметил, что мне нужно обратить внимание, в каком порядке связаны ограничения. Например: (A и B) или C не равно A и (B или C). Поэтому я закончил с ограничением, которое не представляло запрос, который я хотел построить.

Теперь я определяю свои ограничения, а затем объявляю, как они должны быть связаны, используя обратную польскую нотацию, поэтому мне не нужно заботиться о скобках. Кажется, это работает очень хорошо ...