Пишем свой Orm под Android с канастой и сеньоритами, Часть 2-ая

[kerberos]

Equels → equals, а вообще, чем вызвана необходимость писать имена методов заглавными буквами?

List<Car> cars = Car.Where().Equels(“engine_power”, 120).And().Equels("doors_count", 4).Select();

Вложенные условия, типа, a AND (b = c OR d = e), я так понимаю, не предусмотрены?

Как мне подсказывает опыт работы с ORM, пока запросы достаточно простые, все отличненько, но стоит захотеть чего-нибудь нестандартного, и приходится извращаться со всяками хаками и хитростями.

Какие плюсы Вы планируете получить от использования своего orm вместо обычного jdbc?

[Scogun]

Equels → equals

Подправил, спасибо!

а вообще, чем вызвана необходимость писать имена методов заглавными буквами?

Привычка из Delphi и .Net'а! Стараюсь в Java её не переносить, но как видно, не всегда получается.

Вложенные условия, типа, a AND (b = c OR d = e), я так понимаю, не предусмотрены?

Пока нет. В задумке что-то вроде этого:

And(new OrmWhere().Equals("b", "c").Or().Equals("d","e"))

Как мне подсказывает опыт работы с ORM, пока запросы достаточно простые, все отличненько, но стоит захотеть чего-нибудь нестандартного, и приходится извращаться со всяками хаками и хитростями.

Избежать хаков и хитростей планирую, дав возможность делать выборку прямо запросом, но детали пока не продумывал. Еще есть идея сделать все же третий тип аннотации @ViewColumn для свойств выбираемых из view, ну и плюс все сопутствующую архитектуру их (view) создания и поддержки.

Какие плюсы Вы планируете получить от использования своего orm вместо обычного jdbc?

Ну, я уже их получил: пишу приложение под Android и использую свой же orm, благодаря чему как раз и избегаю пока

всяких хаков и хитростей

[hardex]

Проблема составных запросов решается вводом объектов типа Query (.where() возвращает пустой Query) и методов их комбинирования .and(other), .or(other) и т.д.

[Scogun]

Может быть я что-то не правильно понял, но по-моему у меня так и сделано?