RawQuery annotation

[dkaera]

Some time ago I started working on the RawQery integration, which should extend the functionality of the Floor framework. I build on the capabilities of RawQuery in Android Room and define the following specification:

• Define a method in the DAO interface with the @rawQuery annotation and the SQLiteQuery parameter;
• The SQLiteQuery object contains a SQL query string and a list of argument objects;
• SQL query String must work with the database-view;
• The return type can be any primitive Dart type (String, int, double, bool) or model associated with a DAO;

I think the most interesting use case of RawQuery is the introduction of common parameters into the query, like in this issue

[dkaera]

So if I understand it correctly your PR will make it possible that the COUNT type row queries will be able to be at DAO level (where they should be)?
I think this should be solved in the context of this feature.
You are modifying the analyzer for that. Will there be any breaking changes regarding the current database.rawQuery?
No braking changes here, just a new feature in DAO
Will it be able to handle the DISTINCT use-case by any chance?
Yes, I think.

[MrCsabaToth]

Some questions:

• How will the @RawQuery relate to the current @query annotation? (So far it seems to me that they are independent).
• Why is it exactly better than the current @query? I assume the current @query can only return List of entities and no primitive types (?).
• If primitive types are supported, will there be a DISTINCT type raw query resulting in a list of Strings supported?
• COUNT is a special case, because in that case the query returns a scalar only. Bubbling through the layers it comes through as a dictionary item of a list of a sole result. The query needs to be outside of the DAO class right now, with this PR the query can be inside the DAO as one of the "find" type methods?

[dkaera]

How will the @RawQuery relate to the current @query annotation? (So far it seems to me that they are independent).

These two annotations are independent.

Why is it exactly better than the current @query? I assume the current @query can only return List of entities and no primitive types (?).

Good point. This leads me to think that we need to allow any other return entity type on any DAO, at least for RawQuery. I think it's impossible in the current architecture. Looks like a feature for Floor 2.

In fact, the current implementation only solves the case when you need to override a SQL query in an inherited class because the annotation parameters are immutable and must be persistent. And of course, you can define RawQuery in DAO directly. That's the main difference.

If primitive types are supported, will there be a DISTINCT type raw query resulting in a list of Strings supported?

Yes, but it has to be supported by query as well. That's why I moved the primitive types support as a separate function.

COUNT is a special case, because in that case the query returns a scalar only. Bubbling through the layers it comes through as a dictionary item of a list of a sole result. The query needs to be outside of the DAO class right now, with this PR the query can be inside the DAO as one of the "find" type methods?

I think this can be solved by supporting primitive types. We just need to replace the actual mapping by getting one value and casting it to a return value.

[MrCsabaToth]

Thx!

[MrCsabaToth]

Is this Discussion a broader version of #689 ?

[dkaera]

I think it's better to keep it separately. Gave more details in the comment above.

[dkaera]

@MrCsabaToth updated discussion by draft PR. With changes in this PR users might be able to use Count queries or even fetch data from the column directly from DAO classes. If you have any questions or suggestions, please share your opinion :)

[MrCsabaToth]

Ref #517 (comment)