Interesting. Currently I don't use an ORM in my projects solely because if I don't use a CursorAdapter, it's not going to perform well. In addition, we have a fairly large dataset (for a mobile device) that I don't want to have to pull in memory like most ORMS do. If I were able to use an ORM for just saving and updating, then have the ability to also to make a query with a query builder and then use a cursor adapter, that would be a slam dunk for me.
I used OrmLite for Android [1] pretty extensively in a project this spring. I'm not too fond of the DAO pattern, but it did the trick. I ended up using cursors and query builder where it was needed (large lists and such), while using OrmLite for basic CRUD operations.
Certainly more elegant than the SQLite API. Wonder how ORMAN compares though.
yes it is pretty much similar to OrmLite. I haven't tried OrmLite but now looking at the code examples0.
Orman is much easier to use and less boilerplate code. With OrmLite you have more configration and control but from the code examples I looked at, I can say that Orman makes you write really less code.
For example Orman automatically takes entity class fields as columns and generates from name using it. in OrmLite, you always use annotation and give id for it. Orman automatically generates names.
I looked at many-to-many example they have [2], and they are using an intermediate class UserPost to establish relationship. Orman does not need that, it can infer many to many relationship and creates physical join table automatically.
