I've added the Papertrail gem to my app after approx 1000 records have already been created.
Does anyone know how to populate the versions table with the current versions of my data?
Without doing this it seems only the second change for each will allow me to properly make comparisions / flag what has changed via diffing etc.
Many thanks!
A quick and dirty method would be to just create a loop that updates a single field, like adding a space to string field or something harmless.
Related
first let me state that this is NOT a core data migration question. I'm not actually looking at changing the Core Data model, but add additional items during an app update.
The process is as follows:
1) Application is created with a pre-loaded core data. Specifically, a checklist.
2) User can edit this checklist by changing certain values (owned, wanted, etc) but CANNOT remove items
3) I release updates with new items that are added. The users existing data is NOT modified (unless I need to make changes for errata purposes)
I currently manage this by creating NSUserDefaults to check to see if a user has received an update, and if they haven't, add the new items. For example, if a user is going from version 1.4.3 to 1.4.4, the app will check and add the items added in 1.4.4. However, if the app is going from 1.4.0 to 1.4.4, it will check and add items added in 1.4.1, 1.4.2, 1.4.3, AND 1.4.4
. In addition, if a user is installing the app new at version 1.4.4, the newer items are already part of the pre-load and it knows not to apply any of the previous updates. The updates are applied as a .plist/xml file
The system currently works and works well, but it is becoming cumbersome as I now have 38 plist files in my application and 37 if/else statements checking to see if the updates are applied.
There must be a better way. My initial thoughts are to have two databases in the app... One which I update with app updates and the second that is editable by user. Then, with each app update, the database would be compared and any new items in the database would be copied over to the editable store. I'm concerned that this would be a long process though (there are currently over 37,000 items and it's fine when I'm adding 400-500 in an update, but would it take a long time to traverse 37,000 items and copy over new ones?)
I suppose this question may be too subjective for this site, and I apologize if it is, but suggestions would be greatly appreciated!
Zack
You could do this with one pre-load data store and no update property lists or if statements like this:
Store the app current version in user defaults so that during an update you can retrieve it as the previous version (it sounds like you're already doing this, but I wanted to be clear).
In the preload store, add three integer fields that correspond to the major, minor, and point release where that preload item was added. For example, if an item was added in version 1.4.3, major = 1, minor = 4, and point = 3.
When adding new items to the user's data store during an update, get the previous app version from user defaults, and get the major, minor, and point update numbers from that. If the user is upgrading from version 1.4.0, use previousMajor = 1, previousMinor = 4, previousPoint = 0. Make these values default to zero, so that if the user is installing the app for the first time, all three are zero.
Fetch anything that needs to be added from the preload store using a predicate like:
NSPredicate *predicate = [NSPredicate predicateWithFormat:#"major > %d and minor > %d and point > %d",
previousMajor, previousMinor, previousPoint];
Everything that the fetch finds needs to be added. Add it, and you're done.
I need to store a global/class variable that is updated by managers from a web dashboard. The variable will be an array, lets call it car_types. About once a week managers need to go in and change the value. So maybe they'll update from ['suv', 'convertible', 'sedan'] to ['suv', 'convertible'].
What I'm not sure on is where to store this variable.
I could certainly create a database table with one record in it that gets updated, but that seems like overkill.
We use memecached, so I could send the variable there, though I'm not sure if thats persistent enough.
I was thinking of having the dashboard update a class variable, but we have dozens of servers running the same app, and I'm unclear if the change would be replicated to all boxes or just stay on one box.
thanks
Global variables are prefixed by $, example: $cars
But What if your application goes down? The global var is reinitialized to its default value.
I would recommend a database, eventually with caching if you want to save on performances.
You could cache your database values in you $cars variable
That's my personal approach: database + cache for records that being updated not often. cache is cleared when a change is made in the table, and cache is created (with a db request) during first fetch of the record.
As a result its all good cause you have the flexibility to change the records sometimes, no problem arise when the server goes down, or with multi-threading, and the cache permit not to kill performances
I am trying to implement a 'time machine' feature in my grails application. The feature would allow user to select a date in past and would display the interface of the application that was on the selected date. How do I implement this feature? I was thinking of adding a 'dateCreated' field for all domains, so that in the time machine feature, I could query all the results with created date before the selected date. I think this would work but as the data would grow, the size of database would grow and at that time the application would be heavy. Is there any other way to do this ?
Thanks
You could maybe draw some inspiration from this related question:
How to manage object revisions in Grails?
You should look at the http://grails.org/plugin/audit-logging plugin since it will allow you to keep all versions of domain class instances. But implementing this feature will be pretty tricky since object don't exist in isolation - you'll need to not only display the data as of the previous date, but its related data (e.g. the author's books collection) as of that date too. It will make the queries quite complicated.
I have a few data values that I need to store on my rails app and wanted to know if there are any alternatives to creating a database table just to do this simple task.
Background: I'm writing some analytics and dashboard tools for my ruby on rails app and i'm hoping to speed up the dashboard by caching results that will never change. Right now I pull all users for the last 30 days, and re-arrange them so I can see the number of new users per day. It works great but takes quite a long time, in reality I should only need to calculate the most recent day and just store the rest of the array somewhere else.
Where is the best way to store this array?
Creating a database table seems a bit overkill, and I'm not sure that global variables are the correct answer. Is there a best practice for persisting data like this?
If anyone has done anything like this before let me know what you did and how it turned out.
Ruby has a built-in Hash-based key value store named PStore. This provides simple file based, transactional persistance.
PStore documentation
If you've got a database already, it's really not a big deal to create a separate table for tracking this sort of thing. When doing reporting, it's often to your advantage to create derivative summary tables exactly like what you're describing. You can update these as required using a simple SQL statement and there's no worry that your temporary store will somehow go away.
That being said, the type of report you're trying to generate is actually something that can be done in real-time except on extravagantly large data sets. The key is to have indexes that describe the exact grouping operation you're trying to do. For instance, if you're grouping by calendar date, you can create a "date" field and sync it to the "created_at" time as required. An index on this date field will make doing a GROUP BY created_date very quick:
SELECT created_date AS on_date, COUNT(id) AS new_users FROM users GROUP BY created_date
Using a lightweight database like sqlite shouldn't feel like an overkill. Alternatively, you can use key-store solutions like tokyo cabinet or even store the array in a flat file manually but I really don't see any overkill in using sqlite.
I'm looking for some ideas about saving a snapshot of some (different) records at the time of an event, for example user getting a document from my application, so that this document can be regenerated later. What strategies do you reccomend? Should I use the same table as the table with current values or use a historical table? Do you know of any plugins that could help me with the task? Please share your thoughts and solutions.
There are several plugins for this.
Acts_audited
acts as audited creates a single table for all of the auditable objects and requires no changes to your existing tables. You get on entry per change with the changes stored as a hash in a memo field, the type of change (CRUD). It is very easy to setup with just a single statement in the application controller specifying which models you want audited.
Rolling back is up to you but the information is there. Because the information stored is just the changes building the whole object may be difficult due to subsequent changes.
Acts_as_versioned
A bit more complicated to setup- you need a separate table for each object you want to version and you have to add a version id to your existing table. Rollback is a very easy. There are forks on github that provide a hash of changes since last version so you can easily highlight the differences (it's what I use). My guess is that this is the most popular solution.
Ones I have no experience with: acts_as_revisable. I'll probably give this one a go next time I need versioning as it looks much more sophisticated.
I did this once awhile back. We created a new table that had a very similar structure to the table we wanted to log and whenever we needed to log something, we did something similar to this:
attr = object_to_log.attributes
# Remove things like created_at, updated_at, other unneeded columns
log = MyLogger.new(attrs)
log.save
There's a very good chance there are plugins/gems to do stuff like this, though.
I have used acts_as_versioned for stuff like this.
The OP is a year old but thought I'd add vestal_versions to the mix. It uses a single table to track serialized hashes of each version. By traversing the record of changes, the models can be reverted to any point in time.
Seems to be the community favorite as of this post...