sqltoy-orm Addition, deletion, modification and load operation introduction

The last sqltoy-orm best query introduction: http://zhongxuchen.iteye.com/blog/2375088

 

I have always wanted to introduce the regular additions, deletions, and object loading operations of sqltoy-orm, but every time I am too busy or always feel that the additions, deletions and changes are too routine, I have no motivation. But because of this, many people often ask: Is sqltoy-orm just a good query? Even if I stress every time I play hibernate for a long time. The subtext is that it has already absorbed the strengths of hibernate and knows its shortcomings! But the main advantage is that the advantage is not as prominent as the query, so there is no need to emphasize too much.

        Before introducing object operations, first of all, it should be emphasized that sqltoy-orm includes a tool like quickvo, which can help you generate POJO objects from the database through tables (there are also cascading relationships and various primary key strategies). The relationship between the object and the database is automatically annotated through annotation annotations (there are examples in the open source project documentation and the showcase). The biggest advantage of quickvo compared to hibernate-tools is that every time the database changes, the VO will not overwrite your previous changes to the VO. At the same time, the generation strategy of VO can be completely declared in quickvo.xml, unlike hibernate, which sometimes needs to modify POJO annotations (regeneration has to be changed again).

       Closer to home, let's start introducing Sqltoy-ORM object operations (see org.sagacity.sqltoy.support.SqlToyDaoSupport):

  • Object loading:
  1. Load single object loading includes: load(final Serializable entity); load(final Serializable entity, final LockMode lockMode), load(entity, lockMode, dataSource) three methods.
  2. loadCascade cascading loading: loadCascade(Serializable entity, LockMode lockMode) and loadCascade(Serializable entity, Class[] cascadeTypes, LockMode lockMode) two queries, considering performance and flexibility sqltoy separates cascading loading from the loading of the object itself, and at the same time Sub-objects of cascade loading can be specified for precise loading to avoid unnecessary performance consumption.
  3. loadAll batch collection loading: loadAll(final List<?> entities, final LockMode lockMode) for object batch loading. The efficiency of loadAll is actually higher than that of hibernate, and sqltoy is implemented by batch query.
  4. loadAllCascade batch cascading loading: loadAllCascade(final List<?> entities, final Class[] cascadeTypes, final LockMode lockMode); batch cascading loading sqltoy all adopts the batch query method, which is different from the cascading loading of the hibernate loop collection through a single object , the efficiency has been greatly improved.
  • Add save operation to objects: save objects will be cascaded and saved together with sub-table objects.
  1. Save a single object and return the primary key value: Object save(final Serializable entity) or save(final Serializable entity, final DataSource dataSource): Specify the data source to save the object.
  2. Batch save: saveAll(final List<?> entities) or: saveAll(entities, reflectPropertyHandler, dataSource).
  3. Bulk save ignores existing ones: saveAllNotExist(final List<?> entities).
  • Object modification update operation: sqltoy's update operation is very distinctive, completely shielding the defects of hibernate and taking into account the needs of actual business scenarios.
  1. update(Serializable entity): Automatically only modify the properties of the entity object that are not null (scenario: work order processing, only modify some fields in each link), so as to avoid modification of other fields in the database. (Compared to hibernate, you must load and then update to implement this logic, reducing one query and improving performance)
  2. updateDeeply(final Serializable entity): In-depth modification, whether the entity object attribute is null or non-null, will be modified to the corresponding field of the database table.
  3. update(final Serializable entity, final String[] forceUpdateProps) : Modifies the object and specifies which properties are mandatory fields. Compared with 1 and 2, some balance and supplements have been achieved. Combining various scenarios that are very relevant to the project.
  4. updateAll(final List<?> entities) , batch modification: batch modification is performed based on the non-null value of the first record.
  5. updateAll(final List<?> entities, final String[] forceUpdateProps), the specified fields are forcibly modified in batches.
  6. updateAllDeeply(final List<?> entities, final ReflectPropertyHandler reflectPropertyHandler), batch depth modification.
  7. updateCascade(final Serializable entity, final String[] forceUpdateProps,final Class[] forceCascadeClasses, final HashMap<Class, String[]> subTableForceUpdateProps),级联修改,可以指定需要级联修改的子表和子表需要强制修改的属性。
  • 保存或修改saveOrUpdate操作:底层基于不同数据库方言如:merge into 或insert ON DUPLICATE KEY UPDATE  机制,极大的提升了性能。
  1. saveOrUpdate(final Serializable entity):对象保存或修改(已经存在则修改)
  2. saveOrUpdate(final Serializable entity, final String[] forceUpdateProps):保存或修改(针对修改指定哪些字段为强制修改),相对hibernate或mybatis则更加灵活,给开发者带来了更多的选择。
  3. saveOrUpdateAll(final List<?> entities)、saveOrUpdateAll(final List<?> entities, final String[] forceUpdateProps) :批量保存或修改。
  • 对象删除操作:delete或deleteAll。
  1. delete(final Serializable entity):删掉单挑记录,同时会自动根据外键删除级联的子表相关数据。
  2. deleteAll(final List<?> entities):批量删除记录,这个删除相较于hibernate性能更高,底层采用批量删除,尤其子表数据删除也是批量操作,不同于hibernate的循环删除子表。
  • 唯一性验证:isUnique,传递对象判断对象是否已经存在。经常在数据保存前需要判断数据库中是否已经存在,从而提前进行提醒,让交互更加友好(尤其页面维护数据,当维护一个数值后通过ajax判断是否已经存在,避免提交后通过异常来方式提醒用户)。
  1. isUnique(final Serializable entity):根据主键判断是已经重复。
  2. isUnique(final Serializable entity, final String[] paramsName):指定需要判断重复的属性字段进行验证唯一性。
  • 查询并锁定再进行修改并返回结果(一次性交互中完成)
  1. List updateFetch(final QueryExecutor queryExecutor, final UpdateRowHandler updateRowHandler):锁定记录并进行修改,并返回结果,在并发抢占模式下非常有用,如餐厅点桌子,任务竞争性领取等,谁先执行先锁定则先修改先获取(修改后状态发生变化别人就会抢占失败)。 

 

 

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326310695&siteId=291194637