-
Notifications
You must be signed in to change notification settings - Fork 16
Persist on SQLite
There are many ORM or ORM-light libraries. But i want a really simple method to work with SQLite. To work with SQLite means you need to define the database and methods, grouped by DAO to work with bean types supported.
Kripton persistence libray allows to manage persistence on SQLite database implementing Dao pattern. As state in definition of DAO pattern, there are:
- a Data Access Object interface: This interface defines the standard operations to be performed on a model object(s).
- a Model Object: is a simple POJO containing get/set methods to store data retrieved using DAO class.
- a Data Access Object implementation: this contains all boilerplate code that Kripton annotation processor will generate for us.
Once done Kripton Library setup, before use Kripton to persit on SQLite database, an Android app have to initialize Kripton library. To do this, just add
the initialization code in the onCreate
method of used Application
class.
// set context for Kripton Library
KriptonLibrary.init(this);
Just remember to check if application class is correctly inserted into manifest
file.
The bean to persist with SQLite database is defined in this manner:
@BindTable
public class User {
public long id;
public String email;
public String name;
public String surname;
public String username;
}
It is also possible use @BindType instead of @BindTable.
The SQLite data source definition is done with a simple interface:
@BindDataSource(fileName = "security.db" , daoSet={DaoUser.class})
public interface SecurityDataSource {
}
In the datasource definition there is a DAO definition named DaoUser
. This DAO have to define methods to do CRUD operations: read, write, insert and update a bean in the SQLite database.
@BindDao(User.class)
public interface DaoUser {
@BindSqlInsert
public long insert(User bean);
@BindSqlUpdate
public long update(User bean);
@BindSqlDelete(where="id=${id}")
public long delete(long id);
@BindSqlSelect(where="id=${id}")
public User selectById(long id);
@BindSqlSelect(where =" name=${name}")
public List<User> selectById(String name);
}
Kripton requires that every database table has a primary key. For performance reason, table's id have to be of type long
.
It's possible to define a primary key for a table in differente ways:
- define in the associated bean a
long
orLong
field namedid
. - define in the associated bean a
long
orLong
field annotated with@BindColumn(columnType=ColumnType.PRIMARY_KEY)
Given DaoUser
DAO and SecurityDataSource
interfaces, Kripton Annotation Processor will generate for us DaoUsercodeImpl
and BindSecurityDataSource
to work with SQLite database. In this way, after run annotation processor to generate classes associated to data source and dao, to work with database we will use this code:
...
// automatically open and close database connection
try (BindSecurityDataSource dataSource=BindSecurityDataSource.open()) {
final User user=new User();
dataSource.getDaoUser().insert(user);
}
Or, if you need to work with transaction:
final User user=new User();
...
BindSecurityDataSource dataSource=BindSecurityDataSource.instance();
dataSource.execute(new Transaction() {
@Override
public TransactionResult onExecute(BindSecurityDaoFactory daoFactory) {
daoFactory.getDaoUser().insert(user);
return TransactionResult.COMMIT;
}
});
Or, if use Java 8 source code level
final User user=new User();
...
BindSecurityDataSource dataSource=BindSecurityDataSource.instance();
dataSource.execute(daoFactory -> {
daoFactory.getDaoUser().insert(user);
return TransactionResult.COMMIT;
}
});
You can also use batch mode, that is similar to transaction mode, with the difference that batch mode does not use transaction to do operation, simply the operations grouped share same connection.
final User user=new User();
...
BindSecurityDataSource dataSource=BindSecurityDataSource.instance();
dataSource.executeBatch(daoFactory -> {
daoFactory.getDaoUser().insert(user);
return null;
}
});
- 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