Keep sections for DAOs about greendao HOT 12 OPEN

To everyone interested in this: please state what's your use case for this. Maybe we can offer better alternatives in the future.

from greendao.

I would like to see that. Another possibility would be to generate an EntityDaoBase and have an EntityDao that extends EntityDaoBase - or would that break some private API?

from greendao.

UseCase 1#: If you want to sync from a Webservice you want something like a updateOrInsert
UseCase 2#: I could imagine some nice scope methods for predefined QueryBuilders

from greendao.

I expected those use cases and think that there may be better solutions to those:
Use case 1: insertOrReplace does not work for you? Please also check issue #32.
Use case 2: How about generating those queries (in a future version)? Check issue #33.

What do you think?

from greendao.

#1 insertOrReplace looks great!
#2 The generation looks cool, but if you want to do really complex stuff it will be hard to create a good DSL for that (currently no use case on hand). I guess going for keep sections is easier to implement.

from greendao.

Yes, I agree. we should probably go for both.

from greendao.

#1 When I have to obtain objects from a webservice and create the entities in the model, I think the parse+insertOrReplace method should be something encapsulated in the DAO.
#2 Complex queries should also be encapsulated in the DAO. I don't need them be automatically generated, but I would like to have them in the DAO rather than someplace else.

Keep sections would both solve this scenarios.
How do you guys currently implement these kind of scenarios?

from greendao.

i actually disagree for #1. that responsibility belongs to business logic. imho, some other code should handle the request, parse it, validate it and than add to DB. (at least this is how we do it). Parsing objects requires having annotation support in our case which we added to greenDAO and I'm still hoping to keep my promise to send a patch to Markus.

for #2, we've encapsulated all DAO operations inside custom models which can be backed by different data structures (for now we have greendao and lruCache) this helps us depend as minimum as possible on green dao. so generating all complex queries, caching them etc. is a responsibility of these model classes.

We've also changed code generator a little bit to produce two classes, Entity and EntityBase. Entitiy extends EntityBase and EntityBase is an abstract class. Entity is an empty class and only has constructors matching EntityBase. This way, we write all of the custom code to Entity classes and are able to extend basic setters and getters, which comes handy in may situations like parsing server request.

this is how we do it, not necessarily the best way but been working nice so far for us. (https://github.com/path/greenDAO)

from greendao.

There are definitely other ways to do it, but under some architectures, it would be simpler to be able to embed frequent queries into the DAO rather than repeat them in multiple places.

Given we can do this for entities is there a good reason not to have this for DAOs? It would at least be consistent...

from greendao.

If we ever support annotation processing, this might be an issue.

from greendao.

@Keep annotation have no effect on generated dao class

from greendao.

@pzhangleo Please file a separate issue with more details (example) about your problem! Note: @Keep annotations can only be used in entity classes, not the generated DAO classes. -ut

from greendao.