ActiveRecord的ORM问题域 Q&A

本文探讨了ActiveRecord在解决ORM常见问题方面的策略,如避免加载大量数据、存储对象图的更新、同步内存与持久状态等,并对比了与Hibernate的不同之处。

切尔斯基的ORM问题域 ,他提供了Hibernate的解答,现在来看看在ActiveRcord中是如何解决的。大多数解决方案都大同小异,但有些完全不同。

1. 加载根对象时如何避免加载大半个数据库

    同样,“更多的时候,这是一个建模问题”。使用eager load还是lazy load是用户的选择,根据特定场景而定。

 

    ActiveRecord和Hibernate一样,即可以在模型之间指定load方式,也可以在特定查询里面eager load,根据上句话,后者是更好的选择。

 

    Session per request, Open Session in View pattern

 

 

 

    Database Connection

 

     在非线程安全时,每个application instance都会被分配一个database connection。实现线程安全之后:

 

写道
Instead of a single database connection for a given Rails instance, there will be a pool of connections, allowing N database connections to be used by the M requests executing concurrently. It also means allowing requests to potentially execute without consuming a connection, so the number of live, active connections usually will be lower than the number of requests you can handle concurrently.
 
2. 存储时如何更新整个对象图

    切尔斯基已经做了解答:

切尔斯基 写道
框架支持级联更新. 是否应该级联更新, 哪些操作可以级联, 哪些不可以, 对象之间的哪些类型的关联可以级联, 哪些不可以, 则是程序员的责任。
3. 存储时如何高效地更新整个对象图

    答案未知。

 

4. 何时同步对象的内存状态和持久存储状态

    基本上在transaction commit的时候。另外reload方法也会导致内存状态和持久存储状态的更新。

 

5. 如何确保在出错时保持对象内存状态和持久存储状态之间的一致性

 

切尔斯基 写道
数据库事务回滚, 清空内存缓存, 重新加载

 

6. 如何保证引用的唯一性以避免可能的更新冲突

    这个答案跟Hibernate的实现有很大不同(至少目前,Rails2.3.6)

 

    ActiveRecord没有实现Identity Map。当然你要是想用,可以在这里找到一个简单实现:http://github.com/pjdavis/identity-map 。不过ActiveRecord的identity map好像已经在计划之中了。

 

    所以,如果两个对象持有同一个record,则互相并不会知道对方的存在。如下:

 

user1 = User.find(1)
user2 = User.find(1)

user1.update_attribute(:name => 'fuck')
user2.save  // 覆盖上个更新 

 

7. 性能优化问题
  1. N+1查询问题

  2. 分离查询模型和存储模型

  3. 尽量减少查询语句

    关于1和3,在我的这篇文章中有详细解释:http://huzhenbo.name/blog/2010/01/16/rails-performance-tuning

 

8. ActiveRecord Query Cache
写道
Query caching is a Rails feature that caches the result set returned by each query. If Rails encounters the same query again during the current request, it will used the cached result set as opposed to running the query against the database.

 

     ActiveRecord的query cache起到和Hibernate中的session一样的第一级缓存的作用。

 

Reference:

http://martinfowler.com/eaaCatalog/identityMap.html

http://takacsot.freeblog.hu/Files/martinfowler/identityMap.html

 

 

----EOF----

 

 

内容概要:本文详细记录了对一个Android ARM64静态ELF文件中字符串加密机制的逆向分析过程。该ELF文件的所有字符串均被加密,无法通过常规strings命令或IDA直接识别。作者通过分析发现,加密字符串存储在.rodata段,其解密所需信息(包括密文地址、长度和16位密钥)保存在.data.rel.ro段的40字节描述符中。核心解密函数sub_10F408采用自反的双pass流密码算法,结合固定密钥KEY_TERM(由.data段24字节数据计算得出),实现字节级非线性、位置与长度相关的加密。文章还复现了完整的Python解密脚本,并揭示了该保护机制的本质为代码混淆而非强加密,最终成功批量解密全部956条字符串,暴露程序真实行为,如shell命令模板、设备标识篡改、网络重置等操作。此外,文中还提及未启用的自定义壳框架及其反dump设计。; 适合人群:具备逆向工程基础的安全研究人员、二进制分析人员及对ELF保护技术感兴趣的开发者。; 使用场景及目标:①学习ELF二进制中字符串加密的典型实现方式与逆向突破口;②掌握从结构识别、函数追踪到算法还原的完整逆向流程;③理解“绑定二进制”的完整性校验设计及其局限性;④实践编写IDAPython脚本自动化提取与解密敏感数据。; 阅读建议:此资源以实战案例驱动,不仅展示技术细节,更强调逆向思维与验证方法,建议读者结合IDA调试环境,逐步跟随文中步骤进行动态分析与算法验证,深入理解每一步的推理依据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值