ORMLite移动数据库ORM入门与配置指南

ormlite

4星 · 超过85%的资源需积分: 9 131 浏览量更新于2024-07-25 3 收藏 480KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

ORMLite 是一个轻量级的对象关系映射 (Object-Relational Mapping, ORM) 库，用于移动设备和Java平台。这个版本是4.45，发布于2013年3月，由Gray Watson开发并遵循Creative Commons Attribution-Share Alike 3.0许可证。手册详细介绍了如何在项目中集成和使用ORMLite，包括下载库、配置类和数据访问对象 (DAO)，以及支持的功能特性。 1. **开始使用**：获取ORMLite JAR包是第一步，可以从项目管理工具（如Maven或Gradle）中添加依赖。然后，配置类需要添加ORMLite注解来指定数据库结构，并确保有一个无参数构造函数以便实例化DAO。 2. **设置类和DAO**： - **ORMLite注解**：使用ORMLite提供的注解，如@Table、@Column等，来声明数据库表和字段属性。 - **JPA注解兼容性**：虽然主要关注ORMLite自己的注解，但还支持Java Persistence API (JPA) 注解，允许开发者在不改变原有代码结构的情况下进行迁移。 - **构造函数**：必须提供一个无参数构造函数，这是ORMLite自动创建DAO实例所依赖的。 3. **持久化数据类型**：ORMLite支持多种数据类型，包括基本类型、自定义类型和集合类型，确保了数据的一致性和正确存储。 4. **连接源**：你可以选择不同的连接源，例如内存数据库、SQLite、H2等，根据项目需求选择合适的数据库实现。 5. **DAO设置和管理**：创建DAO实例后，可以执行增删改查操作。ORMLite提供了方便的方法来处理数据，比如save(), delete(), query()等。 6. **支持的数据库**：ORMLite针对不同的数据库平台进行了优化，确保跨平台兼容。 7. **表和模式创建**：ORMLite提供TableUtils和TableCreator类来自动化表和模式的创建，减少了手动编写SQL的繁琐。 8. **主键策略**： - **Identity Columns**：ORMLite支持几种主键策略，包括字段标识、自动生成ID（默认）、以及使用序列生成唯一ID。 - **字段类型与主键结合**：字段可以标记为具有`id`、`generatedId`或`generatedIdSequence`属性，影响主键生成规则。 9. **DAO用法**：DAO不仅仅局限于CRUD操作，还包括查询和索引功能，如执行复杂查询和创建索引以提高性能。 10. **原生SQL支持**：如果需要，用户可以直接通过ORMLite执行原始SQL语句，提供了灵活性。 11. **查询处理**：支持通过ORMLite封装的API执行SQL查询，同时也支持更高级的查询选项，如分页和条件过滤。 ORMLite手册提供了全面的指南，帮助开发人员快速上手，无论你是初次使用ORM还是希望在现有项目中引入ORMLite，都能找到所需的信息和示例。它旨在简化移动应用的数据库管理，提升开发效率。

资源详情

资源推荐

10Chapter 2: How to Use 18 March 2013

In our example, the foreign ﬁelds in Question and Answer could be set to auto-

refresh. If this is true then with the maxForeignAutoRefreshLevel set to 1,

when you query for a Question, the Answer ﬁeld will be auto-refreshed, but

the Question ﬁeld on the answer will only have its id ﬁeld set. It will not be

auto-refreshed.

allowGeneratedIdInsert

If this is set to true (default is false) then inserting an object with the ID ﬁeld

already set will not override it with a generated-id. This is useful when you have

a table where you are inserting items that sometimes have IDs and sometimes

need them generated. This only works if the database supports this behavior

and if generatedId is also true for the ﬁeld.

columnDefinition

If this is set with a string then it will be used to deﬁne the column in the CREATE

TABLE statement. By default the database type is used to auto-generate the SQL

necessary to create the column. The column name is provided by ORMLite.

For example:

@DatabaseField(columnDefinition = "LONGBLOB not null",

dataType = DataType.BYTE_ARRAY)

public byte[] bigBunchOfBytes;

foreignAutoCreate

Set this to be true (default false) to have the foreign ﬁeld automatically created

using an internal DAO if its ID ﬁeld is not set (null or 0). So when you call

dao.create() on the parent object, any foreign ﬁeld that has this set to true

will possibly generate an additonal create call via an internal DAO. By default

you have to create the object using its DAO directly. By default you have to

create the object using its DAO directly. This only works if generatedId is

also set to true.

// the account field in Order has foreignAutoCreate=true

Order order1 = new Order();

// account1 has not been created in the db yet, id field is null

order1.account = account1;

// this will create order1 in the order table _and_

// pass order1.account to the internal accountDao.create().

orderDao.create(order1);

version

Set this to true (default false) to have this ﬁeld be a version for the row. A

version ﬁeld adds restrictions when an object is updated to the datbase that

protects against data corruption when multiple entites are updating the row

at the same time. This is very useful in distributed database scenarios if (for

example) a utility process is updating an Account and you don’t want to protect

against overwriting a user update from the web-server.

1. The current-value of the version ﬁeld is read from the object

2. The update statement is augmented with a "WHERE version = current-

value"

11Chapter 2: How to Use 18 March 2013

3. The new-value being updated in the database is changed by ORMLite to

be the current-value + 1 or the current java.util.Date

4. If the row has been updated by another entity then the update will not

change the database since the current-value will not match the version

column in the database and 0 rows changed will be returned by the update

method

5. However, if the current-value does match the version ﬁeld in the database

then the row will be updated, the object’s version ﬁeld will be set by

ORMLite to the new-value, 1 will be returned from update

Only the following ﬁeld types are appropriate for version ﬁelds: short,

integer, long, and Date ﬁelds. Date can also be stored as a string (dataType

= DataType.DATE_STRING) or long (dataType = DataType.DATE_LONG).

NOTE: If you deﬁne a Date ﬁeld to be a version then you can also use it as

a modiﬁcation time on the row. When the object is created in the database,

the version ﬁeld will be automatically inserted with the current Date. When

the object is updated, the version ﬁeld will be updated with the current Date.

Something like the following works well (the dataType=... is optional):

@DatabaseField(version = true, dataType = DataType.DATE_LONG)

private Date lastModified;

foreignColumnName

Name of the foreign object’s ﬁeld that is tied to this table. This does not need to

be speciﬁed if you are using the ID of the foreign object which is recommended.

For example, if you have an Order object with a foreign Account then you may

want to key oﬀ of the Account name instead of the ID.

NOTE: Setting this implies foreignAutoRefresh is also set to true because

there is no way to refresh the object since the id ﬁeld is not stored in the

database. So when this is set, the ﬁeld will be automatically refreshed in another

database query.

2.1.2 Using javax.persistence Annotations

Instead of using the ORMLite annotations (see Section 2.1.1 [Local Annotations],

page 5), you can use the more standard JPA annotations from the javax.persistence

package. In place of the @DatabaseTable annotation, you can use the javax.persistence

@Entity annotation. For example:

@Entity(name = "accounts")

public class Account {

...

The @Entity annotations can have an optional name argument which speciﬁes the table

name. If not speciﬁed, the class name with normalized case is used by default.

Instead of using the @DatabaseField annotation on each of the ﬁelds, you can use

the javax.persistence annotations: @Column, @Id, @GeneratedValue, @OneToOne,

@ManyToOne, @JoinColumn, and @Version. For example:

14Chapter 2: How to Use 18 March 2013

Account() {

// all persisted classes must define a no-arg constructor

// with at least package visibility

}

...

}

2.2 Persisted Data Types

The following Java types can be persisted to the database by ORMLite. Database

speciﬁc code helps to translate between the SQL types and the database speciﬁc handling

of those types. See Section 5.3 [Database Type Details], page 56.

String (DataType.STRING)

Persisted as SQL type VARCHAR.

String (DataType.LONG_STRING)

Persisted as SQL type LONGVARCHAR which handles longer strings.

String (DataType.STRING_BYTES)

A Java String persisted as an array of bytes (byte[]) with the SQL type

VARBINARY. Many databases are Unicode compliant (MySQL/Postgres) but

some are not (SQLite). To store strings with accents or other special charac-

ters, you may have to encode them as an array of bytes using this type. By

default the Unicode Charset is used to convert the string to bytes and back

again. You can use the format ﬁeld in DatabaseField to specify a custom

character-set to use instead for the ﬁeld. Comparison and ordering of this type

may not be possible depending on the database type.

boolean or Boolean (DataType.BOOLEAN or DataType.BOOLEAN_OBJ)

Persisted as SQL type BOOLEAN.

java.util.Date (DataType.DATE)

Persisted as SQL type TIMESTAMP. This type automatically uses an internal ?

argument because the string format of it is unreliable to match the database

format. See Section 3.6 [Select Arguments], page 45. See also DATE_LONG and

DATE_STRING.

NOTE: This is a diﬀerent class from java.sql.Date which is handled by

DataType.SQL_DATE.

NOTE: Certain databases only provide seconds resolution so the milliseconds

will be 0.

java.util.Date (DataType.DATE_LONG)

You can also specify the dataType ﬁeld to the @DatabaseField annotation as

a DataType.DATE_LONG in which case the milliseconds value of the Date will be

stored as an LONG. See also DATE and DATE_STRING.

NOTE: This is a diﬀerent class from java.sql.Date which is handled by

DataType.SQL_DATE.

剩余90页未读，继续阅读

北漂周

粉丝: 3123
资源: 16

ORMLite移动数据库ORM入门与配置指南

ORMLite 用户手册

Android ORMLite关联查询

ormlite 列表局部更新

ORMLite存数组对象

ormlite如何关闭数据库

android ormlite 倒序

在安卓开发中，如何用Ormlite框架实现CRUD操作，并且给出实现代码

ormlite 列表根据条件选择是否更新所有字段

ormlite清空数据库

ormlite 列表根据条件选择是否更新所有字段为传入的实体类

那么，请用Ormlite框架在安卓中实现一个具体实例，请给出我Bean类，数据库Helper类，Dao类，以及实现类

针对 Android 的本地数据库，还有哪些 ORM 的框架，试着找出三种，并说 明使用方法。

针对Android的本地数据库，还有哪些ORM的框架，试着找出三种，并说明使用方法。

sqlite的持久层框架

android studio sqlite案例

Android Dao层

安卓增删查改的底层逻辑

创建联系人的实体类 Contact 继承 OrmObject 并添加相应注解，创建数据库对应类ContactStore 继承 OrmDatabase 并添加相应注解，编写数据库工具类DataContactUtil 封装数据库初始化及对联系人的增、删等功能。

Android常用第三方库

最新资源

针对 Android 的本地数据库，还有哪些 ORM 的框架，试着找出三种，并说明使用方法。