-
Notifications
You must be signed in to change notification settings - Fork 16
Data model, DAOs and data source
Kripton uses the DAO pattern to approach the database management. In the DAO pattern there are:
- A data model composed of simple POJO objects in Java world, and tables in the SQLite world.
- Data Access Object interfaces that define how to access to the database
- Data Access Object implementation that implements the DAO interfaces
- A database that is composed of DAOs and data model.
Kripton needs the developer defines the data model with @BindTable
annotated java classes, the DAO’s interfaces with BindDao annotated Java interface and a data source (the database) by a BindDataSource
annotated Java interface. At compile time, Kripton will generate all needed code to implements DAO interfaces and for managing data source.
We can take the previous Person
example to see how to define an SQLite database with a person table, and a DAO interface with some methods to do CRUD operations (Create Read Update Delete). The data model is represented by Person class:
@BindSqlType(name="persons")
public class Person{
public long id;
public String name;
public String surname;
public String email;
public Date birthDate;
}
Just two things:
- every SQLite table needs an
id
column of type Long or long. It’s a constraint that Kripton required for every table and it is a best practice for SQLite databases. - @BindSqlType is the annotation used to mark a data model that will be used in an SQLite database.
The DAO interface definition is:
@BindDao(Person.class)
public interface PersonDao {
@BindSqlSelect(orderBy="name")
List<Person> selectAll();
@BindSqlSelect(jql="select * from person order by name")
List<Person> selectTwo();
@BindSqlSelect()
List<Person> selectThree(@BindSqlDynamicOrderBy String orderBy);
@BindSqlSelect(where = "id=${work.id}")
List<E> selectById(@BindSqlParam("work") E bean);
@BindSqlInsert
void insert(Person bean);
@BindSqlUpdate(where = "id=${work.id}")
boolean update(@BindSqlParam("work") Person bean);
@BindSqlDelete(where = "id=${work.id}")
boolean delete(@BindSqlParam("work") Person bean);
}
The data source definition:
@BindDataSource(daoSet= { PersonDao.class }, fileName = "person.db", log=true)
public interface PersonDataSource {
}
When the project is compiled, Kripton annotation processor will generate for us the code that implements the data source defined by the data model, the DAO and data-source interfaces.
The need annotations to define a data source with Kripton are:
- BindDataSource: defines a data-source
- BindDao: define the DAO interface
- BindSqlType: associate a class to a table
- BindInsert|BindUpdate|BindSelect|BindDelete: defines SQL to manage tables
In the application, to use generated an implementation of data-source you can use code like this:
// typically Kripton library is done in Application#onCreate
KriptonLibrary.init(context);
// usage example 1: open data source and insert somedata
try (BindPersonDataSource dataSource = BindPersonDataSource.open())
{
dataSource.getPersonDAO().insert(person);
}
// usage example 2: using transaction
BindPersonDataSource.instance().execute(daoFactory -> {
PersonDao dao=daoFactory.getPersonDao();
dao.insert(person);
...
return TransactionResult.COMMIT;
});
// usage example 3: using shared connection
BindPersonDataSource.instance().executeBatch(daoFactory -> {
PersonDao dao=daoFactory.getPersonDao();
dao.selectAll();
...
});
For a PersonDataSource
interface, Kripton generates a BindPersonDataSource
class that implements the data-source which allows to work in a thread-safe way and exposing all DAO defined in PersonDataSource interface. The generated data-source exposes some methods to work in a transaction mode and in shared connection mode.
- Introduction
- Goals & Features
- Kotlin
- Immutable or Mutable Pojo
- Annotation Processor Args
- Credits
- Articles
- Benchmarks
- Setup
- Tutorial
- Usage
- Dependencies and inspirations
- Stackoverflow
- Documentation
- SQL logging
- Data source options
- Indices
- SQL Type adapter
- Global SQL Type adapter
- Constraints
- Live data: welcome Architectural components!!
- Paged Live data
- Dynamic parts
- Transactional and batch operations
- Async Transactional and batch operations
- Global transaction
- Support for immutable POJO
- Generate Content provider
- Generate Database schema generation
- Database migration
- BindSqlColumn
- BindContentProvider
- BindContentProviderEntry
- BindContentProviderPath
- BindDao
- BindDaoMany2Many
- BindDataSource
- BindDataSourceOptions
- BindDataSourceUpdateTask
- BindIndex
- BindSqlRelation
- BindSqlAdapter
- BindSqlChildSelect
- BindSqlDelete
- BindSqlDynamicOrderBy
- BindSqlDynamicWhere
- BindSqlDynamicWhereParams
- BindSqlInsert
- BindSqlPageSize
- BindSqlParam
- BindSqlSelect
- BindSqlUpdate
- BindSqlType
- BindSqlTransaction