rich / acts_as_revisable

A framework for building heavily versioned applications — Read more

Sort by: Priority | Votes | Last Updated

Loading…

7.

0 votes

Branching from current revision doesn't save the revision number branched from
1 comment Created 3 months ago by mheffner

Title

Body
If 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?
or cancel

If 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

mheffner Tue Oct 06 11:09:37 -0700 2009 | link

Found the grab_my_branches routine that answered my question.

Comment
Found the grab_my_branches routine that answered my question.
or cancel

Parsed with GitHub Flavored Markdown
8.

0 votes

Loading a revision loads revision class instead of revisable class
4 comments Created 2 months ago by cblunt

Title

Body
If I have a revisable class `Person` and `PersonRevision`, any time I load a revised `Person`, the result is a `PersonRevision` class (instead of a `Person` class). 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.erb` instead of `_person.html.erb`. Is this the expected behaviour; if so is there a automatic method to cast the revised `PersonRevision` to a `Person` class? Thanks! Chris
or cancel
If I have a revisable class Person and PersonRevision, any time I load a revised Person, the result is a PersonRevision class (instead of a Person class).

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.erb instead of _person.html.erb.

Is this the expected behaviour; if so is there a automatic method to cast the revised PersonRevision to a Person class?

Thanks!
Chris
Comments
cblunt Tue Oct 20 01:47:55 -0700 2009 | link
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 in Person and PersonRevision.
Comment
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 in `Person` and `PersonRevision`.
or cancel
cblunt Tue Oct 20 02:38:42 -0700 2009 | link

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.

Comment
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.
or cancel
rich Tue Oct 20 15:55:17 -0700 2009 | link
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 => @people

As 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 => :revise

That 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.deleted
Comment
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 => @people As 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 => :revise That 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.deleted
or cancel
cblunt Wed Oct 21 00:12:43 -0700 2009 | link

Thanks Rich. I looked a little more into the problem and confirmed that it was due to the limitation of ActiveRecord only allowing one default_scope to be declared.

Unlike named_scope, default scopes aren't merged, so is_paranoid was overwriting AAR's default_scope to only retrieve the current revision.

My Person.find(:all) was therefore finding every revision of every Person, so I had a mixture of Person and PersonRevision classes in the array.

I managed to solve the problem using a fork of is_paranoid http://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

Comment
Thanks Rich. I looked a little more into the problem and confirmed that it was due to the limitation of ActiveRecord only allowing one `default_scope` to be declared. Unlike `named_scope`, default scopes aren't merged, so is_paranoid was overwriting AAR's `default_scope` to only retrieve the current revision. My `Person.find(:all)` was therefore finding every revision of every `Person`, so I had a mixture of `Person` and `PersonRevision` classes in the array. I managed to solve the problem using a fork of `is_paranoid` http://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
or cancel

Parsed with GitHub Flavored Markdown
10.

0 votes

Break out of In-Table Revisions?
4 comments Created 20 days ago by skgma

Title

Body
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?
or cancel

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

rich Fri Dec 11 12:57:08 -0800 2009 | link

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?

Comment
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?
or cancel

skgma Fri Dec 18 12:11:49 -0800 2009 | link

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.

Comment
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.
or cancel

rich Fri Dec 18 12:22:18 -0800 2009 | link

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?

Comment
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?
or cancel

skgma Fri Dec 18 12:31:39 -0800 2009 | link

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.

Comment
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.
or cancel

Parsed with GitHub Flavored Markdown
11.

0 votes

(STI) Revisions of destroyed records does not update 'type' and 'revision_type' attributes
0 comments Created 13 days ago by skgma

Title

Body
This is using Single Table Inheritance. The issue is easily remediated with my childish method: <pre> 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 end </pre> hahaha, 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: <pre> >> RacfAccount.count => 9319 >> RacfAccountRevision.count => 16 >> Account.count => 9319 >> AccountRevision.count => 26 >> </pre> 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!
or cancel
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
  end
```
hahaha, 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

Parsed with GitHub Flavored Markdown