On Dec 28, 2010, at 4:45 AM, Colin Law wrote:
1) Why does it create the user stuff in the vv migration/model - I
dont
have users in this app, should I delete those attributes or just not
worry about them, and it'll just work (tm).
The user stuff relates to which user made these changes, nothing else.
VV can do multi-user edits and tracks which user made each edit. Very
powerful stuff, but I haven't used that feature yet.
2) It seems to be more aimed at REVERTING to previous versions rather
than querying them - to explain, in my app I'd like to keep a
history of
price tiers of apple store apps, so each day an App.tier might
equal a
different value, I might like to print them all out over time or
chart
them or more likely find an apps highest or lowest tier
historically -
is that easy/doable with VV?
If what you want to do is store a set of values for something varying
over time and wish to query the set, pick out max and min and so on
then I suggest this is not best served by versioning. Instead model
it in the normal way. So App has_many price_tiers, PriceTier
belongs_to app, and a PriceTier has a date field you can query on.
Colin
I concur. All I have ever used it for is reverting. I can only query
the current model, since the pickled objects in the VV table aren't
much good for that (barring raw text matching). I make a little
"pager" control in the edit view and step through the available
versions, the user can pick one and decide to revert to it by saving
the object while it is reverted to that particular state (creating a
new max+1 version that is a copy of version N).
Walter
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Talk" group.
To post to this group, send email to rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
