rich / acts_as_revisable
- Source
- Commits
- Network (14)
- Issues (4)
- Downloads (0)
- Wiki (1)
- Graphs
-
Branch:
master
-
Branching from current revision doesn't save the revision number branched from
1 comment Created 3 months ago by mheffnerIf a branch is created from the "current_revision", then branch.branch_source appears to always point to the latest revision of the original branch. Should a branch operation save the revisable_branched_from_revision_number?
Comments
-
Loading a revision loads revision class instead of revisable class
4 comments Created 2 months ago by cbluntIf I have a revisable class
PersonandPersonRevision, any time I load a revisedPerson, the result is aPersonRevisionclass (instead of aPersonclass).This is throwing my partial rendering and link generators. For example:
# app/models/person.rb class Person acts_as_revisable end # app/models/person_revision.rb class PersonRevision acts_as_revision end # app/controllers/people_controller.rb @people = Person.all # app/views/people/index.html.erb <%= render @people -%>For any revised person, the renderer will look for a partial
_person_revision.html.erbinstead of_person.html.erb.Is this the expected behaviour; if so is there a automatic method to cast the revised
PersonRevisionto aPersonclass?Thanks!
ChrisComments
Realised my mistake, I should explicitly set the link_to path in the partial, e.g.:
<%= link_to "edit", person_path(person) -%>However, the partial still loads the record as a PersonRevision class, which doesn't implement the instance methods of Person (e.g.
is_admin?). I'm thinking of moving these methods into a module, and then including that module inPersonandPersonRevision.I'm closing this issue as further looking into the code reveals the issue is caused by my revised model using the is_paranoid plugin alongside acts_as_revisable. I've not looked into the source, but I'm guessing that the default_scopes are conflicting. I'll open a new issue once I've looked into it a little more.
I'm not entirely sure there really is a problem here. Or at least the problem is one of documentation.
What you're seeing is specifically how AAR is designed to work. You could handle this case by providing the partial Rails is looking for or, use the longer form of render like:
render :partial => 'people/person', :collection => @peopleAs for the is_paranoid issue, I'll look into that. One small note, it's not as fleshed out as the rest of the library but, there is some work at supporting is_paranoid type functionality.
acts_as_revisable :on_delete => :reviseThat will flag and store the deleted record instead of deleting it. Then on your revision class there's simple a scope to access those records:
PersionRevision.deletedThanks Rich. I looked a little more into the problem and confirmed that it was due to the limitation of ActiveRecord only allowing one
default_scopeto be declared.Unlike
named_scope, default scopes aren't merged, so is_paranoid was overwriting AAR'sdefault_scopeto only retrieve the current revision.My
Person.find(:all)was therefore finding every revision of everyPerson, so I had a mixture ofPersonandPersonRevisionclasses in the array.I managed to solve the problem using a fork of
is_paranoidhttp://github.com/grioja/is_paranoid which I found via this post http://joshuaclayton.github.com/code/default_scope/activerecord/is_paranoid/multiple-default-scopes.html -
I like the idea of keeping the revisions inside a single table, but after so many revisions... Things get slow. Is there a simple way to have it store the revisions in a separate model/table? I'm not very good at figuring out where things happen in the code, with Ruby, still. Would this be easy for me to do, or is it pretty thoroughly built into how aar works?
Comments
The single-table approach is pretty ingrained into how AAR works.
I'm curious if you can give some details on the performance issues you're having though. Can you give me some examples of what slow and what volume of data you're working with?
I'm sorry for the delayed response, I haven't signed in in a few days. Part of the issue is my design, which InnoDB's lack of FULLTEXT makes pretty painful. And Sphinx can be quirky, so I don't use it during my ETL.
http://pastie.org/private/dyq2votczhekmtiuyz28sa
Before you call me an idiot, part of why things are SO slow is my own idiotic fault. I was learning Rails when I began this thing (converting from a mini-Perl project I wrote before). So I've done all kinds of crazy STI tricks and Polymorphic stuff. The slowdown isn't so much because of AAR, but because the size of the indexes grow very large.
The Accounts table's Data Length is 21.6MB and the Index size is 30.1MB.
My Connects table (has two polymorphic foreign keys, which are used by STI models to represent different types of connects between my tables) is huge:
Connect.count => 201002 ConnectRevision.count => 39378
and it's design is retarded. I'm breaking it out into its own separate tables and getting away from my retarded polymorphic nonsense (except in one case). This will speed it up and AAR is really fine. I just liked the idea of having it be placed into another table to minimize the size of indexes over time. But even then, it's not a big deal--I just need to trim old/useless records.
One thing I did notice is something I'm going to open a ticket for, because I'd be shocked if you've read this far.
Those table sizes aren't particularly large and nothing else you've described sounds so bad. Can you give me some idea what queries are slow? Maybe the output of "show indexes from <table_name>" for accounts and connects?
Here it is:
http://pastie.org/private/pjab3aiwx7ivzidyypfdzw
Thank you for looking. What is slow is during my ETL, where I do an UPDATE on each record. I don't want you to think AAR is especially slow. It's mostly my design and ActiveRecord, IMO. And it's hard for me to tell just how slow it may or may not be with the ~30,000 extra revisions--but it doesn't seem to be as big of a hog as I thought it was.
-
This is using Single Table Inheritance. The issue is easily remediated with my childish method:
acts_as_revisable do revision_class_name "AccountRevision" except [:update_tracker, :last_login_on, :last_update_on, :last_login_at, :password_changed_on, :updated_at, :revoked_on, :resumed_on] end acts_as_revisable :on_delete => :revise after_revise_on_destroy :arod! def arod! print "poop poop!!\n" self.revisable_type = self.type self.type = "#{self.type}Revision" self.revisable_original_id = self.id if self.save return true else return false end endhahaha, it says "poop poop." What a cute definition (snuggles).
I'm porting my models into a new Rails project for cleanliness sake and just realized this issue again. Example:
>> RacfAccount.count => 9319 >> RacfAccountRevision.count => 16 >> Account.count => 9319 >> AccountRevision.count => 26 >>
The AccountRevision is showing records for which the '.destroy' method has been used. The 'type' attribute continues to reflect "RacfAccount" and not "RacfAccountRevision", and the 'revision_type' is set to NULL. However, when doing a simple revision (but not destroy) of a RacfAccount record, it will correctly set the 'type' and 'revision_type' attributes (by default).
Thank you!
Comments





Found the grab_my_branches routine that answered my question.