search

paper-trail-gem / paper_trail

Track changes to your rails models
MIT License
6.8k stars 898 forks source link

Non-ActiveRecord ORM compatibility, e.g. Sequel #370

Closed giosakti closed 6 years ago

giosakti commented 10 years ago

Hi guys,

thanks for the wonderful job on creating and maintaining this wonderful gem.

I have a question to ask, I have a plan to use non-AR ORM (Sequel) for my next project, do you think that I still can use paper_trail gem with Sequel ? (perhaps by modifying or patching some things up)

batter commented 10 years ago

Are you referring to this Sequel? I actually hadn't heard of it until now, so that wasn't a plan I had looked into as maintainer of the gem, but if you or anyone else wants to make a pull request, I'm happy to try to work with it.

giosakti commented 10 years ago

Yup, that's the one.. Ok, I would analyze first how deep is the integration between papertrail and AR and after that I'll see what I can do..

calebwoods commented 10 years ago

@giosakti any thoughts on how difficult this would be from your analysis? Would be very interested in having Sequel support. Thanks.

destroytoday commented 9 years ago

+1

jaredbeck commented 9 years ago

This is related to https://github.com/airblade/paper_trail/issues/308 in the sense that both are about mappers. This issue is about an Object-Relational Mapper (ORM) and https://github.com/airblade/paper_trail/issues/308 is about an Object-Document Mapper (ODM).

The underlying issue in both is that we are missing a level of abstraction. PaperTrail is tightly coupled to ActiveRecord right now. For example, has_paper_trail calls a lot of activerecord methods directly, e.g. has_many, after_create, after_commit, etc.

In order to support sequel, mongoid, rom, or any other mapper, we first have to break that tight coupling by adding a new layer of abstraction. The adapter pattern comes to mind.

jaredbeck commented 6 years ago

Closing due to inactivity. Contributions welcome, as described above.