Another interesting feature would be POJO created by your tool

[druidamix]

Hi,

Using your tool, automatically would create POJO objects and the possibility of fill up the pojos using the cursor or similar object

PD. Sorry, I don't know how to label the issue as enchantment

[BoD]

Hi!

I am under the impression that the use of POJOs is in fact an anti-pattern for Android, where resources (memory, and cpu) are constrained.
I think using POJOs means you're going to create collections of objects = garbage collection = cpu usage...
And I don't want this tool to encourage bad practices :)

[goodev]

@BoD maybe when using with http://square.github.io/retrofit/ need those POJOs, then through POJOs to save data to database.

[ansman]

There are times where cursors just don't cut it.

Let's say you have a these models:

• Author
• Book

You need to be able to show all books grouped by author.
One solution would of course to fetch all authors and then perform one query per author to fetch the books for that author but this isn't very efficient since the number of queries grows with the number of authors.

For me just being able to create a stupid POJO without any way to interact with the DB would be enough.

What I would love is something similar to this:

BookCursor cursor = new BookSelection().query(contentResolver);
cursor.moveToNext();
// This creates a new model from the cursor which copies all the fields
Book book = cursor.cloneModel();
book.setTitle("Some title");
// This creates content values from the model, ready to be put back in to the database
BookContentValues contentValues = book.getContentValues();

With the changes in 1.9 the need isn't as great since the cursors now implement the model interface but it would be nice to be able to give a model to other components without having to worry about things breaking when you move the cursor.

[BoD]

I think your first use case ("show all books grouped by author") is more of a case for joins and group by (which are both already supported) than for POJOs.

Your second use case is interesting: if I understand correctly, you want to be able to create a ContentValues from one row of a Cursor - to easily update one (or a few) column(s) of one particular row.
I can see this could be useful, but I'm not sure this requires the generation of POJOs - there may be other ways.
If we're on the same page, can you open a different issue for this use case?

[ansman]

Well, even with joins you cannot get a multi dimensional result set back since group by only collapses rows that share some property into a single row.

What you could do as I mentioned is this:

AuthorCursor authorCursor = new AuthorSelection().query(contentResolver);
while (authorCursor.moveToNext()) {
  BookCursor bookCursor = new BookSelection()
    .authorId(authorCursor.getId())
    .query(contentResolver);
  // Do something with the books
}

But this would not scale well since the number of queries scales with the number of authors.

I don't see any other solution than to parse each row of the books into a POJO and put them in a map with the author ID as key.

But perhaps there is some other way that I've missed?

[BoD]

In fact, you are right, group by is probably useless in this case. I think this could simply be done by selecting all the books, joining the authors, and sort by author id. Then when iterating over the cursor, look at the author id, if it is different than the previous one, then it's a new "group".

[ansman]

Sure, that works when I need to do something once with the books for each author but say I need to fetch all the books for author X, for example when using a list adapter.
You'll need to have fetched all books in the end but when showing a single item you'll need the books for just one author.

I totally agree that POJOs should be avoided in favor for cursors but sometimes you need a multi dimensional result.

But perhaps this use case isn't common enough to warrant this feature, after all it's not that big of a problem to parse this yourself.

Creating content values from a cursor isn't as attractive (to me at least) if it always contains all fields for a table since some columns might be read only (such as create time, id etc).
But if we had POJOs they could keep track of which fields that have changed and only generate content values for those fields like so:

BookCursor bookCursor = new BookSelection().id(1).query(contentResolver);
bookCursor.moveToNext();
Book book = bookCursor.toModel();
book.toContentValues(); // Empty BookContentValues or null
book.setTitle("Some other title");
book.toContentValues(); // BookContentValues containing only the title
book.setYear(2015); 
book.toContentValues(); // BookContentValues containing both the title and the year

[BoD]

Partially resolved in 1.11.0. You can do:

BookBean.copy(bookCursor)

Closing for now :)