IssueTracker

+1 to an optional annotation

I'm not sure that an optional annotation is good, because people won't have enough understanding if their query fits into 1 cursor window (I think most of the people don't know size of window , they don't know size of one row (and it changes), so it is veeery hard to them to guess). I think that we may have @Yolo annotation, which turns transactions off, so only few people takes this risk and turns them off.

I guess it depends on how common we think it will be to have reads this large. I trust your judgment here.

FWIW, +1 for @Yolo. Mostly, because it's generally better to set the defaults for safety, with ways to opt into performance (with implications of lots of testing). That goes double for a library that is designed to simplify things and therefore will attract a lot of inexperienced developers.

Plus, @Yolo is an awesome annotation name... :-)

When a query returns too many rows to fit in a CursorWindow, how does wrapping it in a transaction make it consistent?

because it holds a transaction in the database, it will isolate the queries.
Cursor does this weird thing where it re-runs the query to fill the next window. Since it is another query, unless there is a transaction, it may load totally different data.

i don't like the idea of turning it on for every single query because it will simply make the db access single threaded for a super super edge case (especially after we have paging).
maybe we can make it a builder parameter (off by default) and also support @Transaction in selection methods?

how about
we can make query -> see that results are larger than page -> add transaction -> rerun query + (print warning ?). So at least we would provide always safe behaviour. Plus we still have unsafe option that turns it off.

i think ccraik@ had a way of figuring it out in the framework SQLiteCursor. Unfortunately, it is hidden because of the abstraction but we can make it a first class api in the abstraction.
I think we can even implement this in the framework impl (db-impl module) to completely hide from the generated code.

this may require an API change so moving to beta1 hotlist.

i think for now we should just ensure that Relationship queries are fetched in a transaction so that they are consistent.

If we can implement this in a cursor wrapper, that would be the best.
Besides, this is something that needs to be handled in the FrameworkSQLiteDatabase since it is the only one that can figure out the windowing.
As long as the Cursor is not passed to the outside world, it seems reasonable to create a cursor wrapper that holds a transaction until it is closed.

decided to punt on this till after 1.0 release.

@transaction is now supported on reads.