enableKeepSectionsByDefault - reasoning

[Amit Rana]

Hi,

 While searching for ORM for android I came across greenDAO, looks great.

 http://greendao-orm.com/documentation/modelling-entities/ talks about enableKeepSectionsByDefault, I am curious why cant we generate BaseEntity and Entity (extends BaseEntity) classes? Entity class is never re-generated (if it exists). So this way we can write code in Entity and BaseEntity can be regenerated everytime we change the scheme.

 Putting custom code between comments doesn't look so clean.

Regards,

Amit.

[Markus Junginger]

Inheritance can be tricky once you add features. E.g. if we would decide to support some kind of entity inheritance and polymorphic queries. I'm not saying that this cannot be solved. It's just hard to predict. Or using an card game analogy, using inheritance is like having a single joker card that you play out only once..

[yiğit boyar]

Hi Markus,

I accept your point. On the other hand, i think this restriction hurts green dao integration.

For example, I'm considering adding green dao to an existing project which has all value object which have many helper methods. It will be really hard to move all of it to a keep section. + for project structure clarity, I prefer to have generated classes in a different folder. 

If GreenDao had this suggested inheritance, I could configure it to generate wrapper classes (empty ones) to my VO folder.

Assuming that properties will be protected not private, all I would need to do would be removing my fields that are persistent from my value objects and I will be good to go. (to be clear, my value objects extend GreenDao models  and all GreenDao classes will return my VOs rather than GreenDao models). In this case, we would make GreenDao models abstract to make sure nothing goes out of control.

I might be missing sth but I really cannot see why such inheritance will hurt further projects, e.g. entity inheritance or polymorphic queries.  Basically, generated code will never ever construct an instance of Model objects, it will always use instances of value objects. (or whatever the extending elements are called which extend base model objects). The only constraint would be to have same constructors of Model objects in VOs.

If you are concerned about time (e.g. implementing this change); I would be happy to implement it and commit to GreenDao Project. But if you are not willing to do such change, it will require us to diverge from the main source code which we would not like to do for further updates & compatibility. 

yigit

[yiğit boyar]

Hi,

I actually hacked sth here: https://github.com/yigit/greenDAO/tree/base_entity

May not be the proper implementation as it is an hour hack but this is what I did:

- Added `classNameBase` property to Entity Object. This name is used for ModelBase classes.

- Renamed entity.ftl to entity-base.ftl which generates abstract base model. Changed private property Fields to protected. (Example NoteBase)

- Added entity.ftl which generates an entity Model class that only has constructors matching super (ModelBase) (Example Note)

- Added an optional parameter to DaoGenerater to be able to export Model classes to a different folder.

With these changes, it achieves what I look for. As I said, I might have missed some parts but these changes work well in my greenDao sample project. (a project that I did to try greenDAO)

I'll be happy if you can review these changes and let me know what you think. If you think it is ok, I'll be happy to fix my potential mistakes and send a pull request.

Thanks,

yigit

[Markus Junginger]

Thanks for looking into this. I'm a little too busy to review now, so forking is fine for now. I might come back to you later tough.