Android LitePal database ORM use summary (a guide to avoiding pits)

LitePal is the open source ORM framework of the author of Android "First Line of Code" Guo Shen, a very useful ORM.

Although it is easy to use, if you don't pay attention, you will encounter many pitfalls. The so-called pit does not mean that the framework is not good, but that there are some details that may make mistakes if you fail to pay attention.

This is not a bug, but no matter the tutorial or the demo, it is rarely mentioned, and can only be summarized one by one during the use process.

The following summarizes the problems encountered in my use, and gradually improves them.

First introduce the simple use:

Add dependency in build.gradle in app directory:

//litepal数据库ORMimplementation 'org.litepal.guolindev:core:3.2.3'

Create a corresponding litepal.xml folder under the assets folder::

<?xml version="1.0" encoding="utf-8"?><litepal>    <dbname value="testdb"/>    <version value="1"/>    <list>        <mapping class="com.test.model.User"/>    </list>   <storage value="mydir" /></litepal>

In the onCreate of Application, add initialization: LitePal.initialize(this); the introduction is complete.

Question one:

The default database storage location problem, you can specify storage value="external" or "internal" in the litepal.xml file, the default is internal, and the file browser view is invisible or has no permissions. External, the database file can be found in the Android/data/ directory. However, regardless of the setting, as long as the application is uninstalled, the database will be cleared.

How to keep the database files persistently, not affected by uninstallation? It's also simple, just change the storage.

For example: storage value="mydir", the database file will be found in the mydir directory under the root directory. But the premise is that this mydir has been created in advance. If it is not created, you will know what will happen if you try it.

Question two:

Multi-table association problem, the associated table cannot be stored in data.

There is a hidden secret here, which is difficult to discover. After establishing a one-to-one association or one-to-many association, you must first remember to save the data in the association table! ! It is not that after you directly assign the data set, the associated table will have data. Set only establishes an association between two tables. And, in addition to save, the set cannot be omitted, otherwise you will see that the content of the foreign key field in the associated table is empty.

Positive solutions such as:

News news=new News();        news.setTitle("这是一条新闻标题");        news.setContent("这是一条新闻内容");        news.setPublishDate(new Date());        Introduction introduction=new Introduction();        introduction.setGuide("这是新闻导语");        introduction.setDigest("这是新闻摘要");        news.setIntroduction(introduction);//只是建立关联;//重点;

Question three:

There are entities with multiple tables associated, and the contents of the associated tables found during query are empty.

For example, an entity is defined, and other entity classes are also associated internally. If you do not pay attention to the query, you can only find the content of the entity, and the associated entity will be empty.

For example:

public  class OrderDishTransdtlRecord extends LitePalSupport {     @Column(nullable = false)    private String billno;// 点餐单号    @Nullable    private String goodsid;//菜品编号 char(16)    @Nullable    private String typename; //菜品类别名称    private int orderno;// 每笔订单菜品序列号    private int price;    private int qty;    @Column(ignore = true)    private List<OrderComboFoodRecord> comboFoods;// 套餐详情,不存数据库    private  List<OrderDishTransdtlRecord> dtlList;// 细节  关联OrderDishDtlRecord.....}

If you just take it for granted LitePal.find(OrderTransdtlRecord.class,10), the dtlList found in this way is null and there is no data. Instead, it should be written as follows:

 OrderTransdtlRecord recc = LitePal.find(OrderTransdtlRecord.class,10,true);//重点,第三个参数必须有,且为true Log.d(TAG,recc.toString());

Question four:

When deleting a record, the content in the associated table should have been deleted, but the data is still there and cannot be deleted. Such as:

 OrderTransdtlRecord recc = LitePal.find(OrderTransdtlRecord.class,10); recc.delete();

In this way, the data in the associated table OrderDishTransdtlRecord of OrderTransdtlRecord cannot be deleted. The reason is similar to the previous one. The query here does not add the third parameter, isEager: True to load the associated models, false not. Add the third parameter, after the query is successful, delete it again, so that the associated table will be deleted. Or use this method, LitePal.delete(OrderTransdtlRecord.class,18), and the associated table will be deleted.

Or in this way, the associated table will also be deleted:

LitePal.deleteAll(OrderTransdtlRecord.class,"id = ? ","19");

Question five:

Enumeration types are not supported in LitePal. If you use enumerated types in your model, the fields of the enumerated type will be ignored in the generated table structure.

Commonly used types such as String, int, and long can be used with confidence. Other types need to be tested and cannot be taken for granted.

There are 8 data types supported by LitePal: int, short, long, float, double, boolean, String and Date. Other unsupported items such as enumeration will be ignored.

And, if table associations are used, they need to be registered in litpal.xml, otherwise, they will be ignored instead of generating the associated table structure.

You also need to pay attention when performing boolean operations. For the LitePal database, when the boolean value is true, you can directly use LitePal to store the object. If the boolean in the stored object is false, you need to call the setToDefault(String name) method to store, where the parameter name is the name of the Boolean attribute in the object , Is a string boolean value is actually stored in the database in the form of 0 and 1, true=1, false=0, so you need to pay attention when querying.

Question six:

The operation of the LitePal database is performed in the main thread by default. When using it, you need to pay attention to handling thread and asynchronous issues.

Although the previous version of LitePal provided asynchronous operation api, the author said, try to use it as little as possible. Subsequent versions may be obsolete and no longer maintained. It is recommended that application developers handle asynchronous issues themselves, such as using the RxJava asynchronous library.

In the continuous summary, welcome to add...