Comments (7)
@stephanenicolas thanks for the suggestion. I agree with you on the constraint it places. Below are some of the reasons why we went this way.. Would like to hear your views on it. Will certainly love to remove that constraint, if there's a better way to do it, while retaining the simplicity and readability intact.
To answer your second question, SugarApp is only needed in the AndroidManifest. If you're planning to do some more work in your own Application class, you could either extend SugarApp or duplicate the code from that class to your own Application class.
The inheritance model enables the near-zero configuration. With a DAO approach, it may need more configuration or set of boilerplate by itself.
Continuing on the inheritance discussion:
Using the inheritance, we're able to detect the entities in your app which helps in DB creation. Also, the syntax looks very readable, since the methods are directly on the object itself.
eg:
new Book("title").save();
from sugar.
Hi Satyan,
quite a prompt answer :) thx.
Regarding the application class inheritance, it would be easy to turn that into a composition. A SugarDatabaseManager could open and close the database and could be added to any app, and the SugarApp class could be turned into a DefaultSugarApp for people would don't use an application class.
I don't see how the DAO could lead to more configuration. Yes, you would have to declare thePOJO classes but a SugarDAO would be as easy to use as the current state of Sugar. It would give something like
Book book = new Book("title");
new SugarDAO<Book>().save(book);
Again, from a design point of view, mandatory inheritance is really too strong. Not every Android projects creates its own POJO classes, some of them "get" them from a server-side project. Moreover you could want to turn them to Serializable stuff or Parcelable to exchange data between Activities or Fragments. The DAO pattern has been invented for this.
from sugar.
@stephanenicolas certainly worth a try.. Let me think over this. The key would be to keep the setup to absolutely minimal.. I see the advantages though.
from sugar.
Hey @satyan,
I've just read through this and I'd have to agree with @stephanenicolas that the inheritance pattern is just a little too strong for my use cases. I'm one of those people who are relying on a dumb serializable POJO to shunt information between activities etc.
While arguably not as clean as the current implementation, what @stephanenicolas is suggesting in terms of API, coupled with the rest of the ideals of Sugar, is far and away cleaner than that of the alternative libraries. In fact, this simplicity is exactly what drew me to Sugar in the first place. By all means if you can munge Java into a more workable ActiveRecord-like API like you want to, that'd be awesome ;)
FWIW, inheriting the project from SugarApp bothers me less, as I don't have any logic in my application, but I do foresee problems if another library wants to do the same also.
Nathan
from sugar.
Hi all,
Found this discussion interesting... but at least one question comes to mind.
I guess Sugar now uses classpath scanning to look for the persistent classes that extend SugarRecord to find all definitions of sugar records, for example, to manage the database schema.
Now i guess if we do not have extension, we need some other explicit way to know which classes are persistent... This could mean annotations (@entity?) and we keep scanning the classpath for "annotated with it" classes, or have another explicit way to manage the db schema (SugarDBSchema.createFor(Entity1.class, Entity2.class)
or am i missing something?
grts,
Pedro
from sugar.
@pguedes yes Pedro.. You're right. We look for all subclasses of SugarRecord hierarchy and create corresponding tables. I'm favouring the annotations approach for better readability.
I did try it out a few days back. @SugarRecord as annotation instead of inheritance. Most of the things worked through well. Haven't tested it thoroughly yet though.
The ActiveRecord style querying takes a hit, but it does remove the constraint of inheritance. I'd probably introduce both syles parallelly.. So for the time being, people could choose which style works for them.
Going forward, we could deprecate the older style in favour of annotations approach, it that's what is favoured.
from sugar.
This has been implemented in 4df07db.
from sugar.
Related Issues (20)
- Support for user specified ID's being used in the database instead of having them generated automatically.
- Android Studio 3.2.1 DB is no longer created HOT 3
- Is Sugar ORM library affected by the newly found SQLite vulnerability?
- update bug HOT 1
- [QUESTION] Where I can find the CI service?
- OneToMany Annotation
- Missing saveAll() for nested Table
- How read existing DB from assets folder? HOT 1
- Como deletar todos os dados de uma tabela e depois verificar se a tabela está vazia? HOT 1
- No such table with migration HOT 2
- ava.lang.NoSuchMethodException: <init> []
- SugarRecord Read / write separation
- bulk data not inserted completely
- Caused by: android.database.sqlite.SQLiteException: no such table: HOT 5
- *.db file is empty, but in application all the lines are shown.
- RuntimeException on start
- 我使用save来保存数据但是数据当中设置了不可重复字段会对其进行覆盖
- build failed when sync graddle HOT 1
- no such column when select
- Could not resolve project :sugar
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sugar.