I'm migrating my application from Rails 3.0.12 to 3.2. I use the active_record_store to work with my session variables, owing the size limits on the default cookie store. On the new version of Rails, however, the session variable is not getting set.
I can see that the cookie session_id is being set with a value, but I can look at the contents of the database and see no values being inserted when a session variable is supposed to be populated.
However, if I switch back to cookie store, it works fine. Is there anything I can check to find out what's going on?
I'm afraid the problem solved itself, perhaps in a Gem update that I performed in preparing to respond to the comments on this question. I had the Rails 3.2 version of my app on a separate Git branch, so I brought it back and merged it with my current development version.... and it all "just works".
I can't help but think this was a transient issue with either an older version of my code or a gem, but it's solved now, so I'll close this question.
Related
We have always had some issues with rails schema file. It got worse after upgraded from rails 3 to rails 4.2. So everytime someone runs "db: migrate" on the local machine, it adds, removes or edit stuff in the schema file. Nothing got affected in the database though.
When we were on Rails3, we got changes like string limit: 255 changes to 100, columns removed and added back in a different row. In Rails 4, apart from the pre-existing ones, we got all the timestamp (created_at, updated_at) added with null: false. We don't set up the default for timestamp in migration files. Also, the index names are changed to those rails generated ones, but we do specify the index names and they are sitting in the database without any issue.
Now it gets really annoying as it causes conflicts on and making noise. Any suggestion to fix this?
User Rails 4.2.10, Ruby 2.5.3, mysql version 5.7.22 by Homebrew.
I am using devise gem for my rails app. Whenever I try to update the settings like max. number of attempts, Password Regex, Lock Strategy etc. I am forced to restart the server, as otherwise the changes do not take effect. This implies that these values are being cached. What is an efficient way to remove cached values in devise?
Everything in app/config folder loads only once during server boot.
Trying to hack won't make your life easier.
(though I want to know if it is possible)
When I update my CoreData model, it crashes the app, So I have to delete the old app, and then reinstall. That's fine with me, but my question is: How do I tell my customer that they must delete the app before they reinstall? This seems too complicated...I am just adding 1 additonal field to a models and that's it.
Is there a better way to deal with this?
Thanks
You need to set up database migration... To upgrade a customer's existing data to the newest data model when they update. For some changes Core Data can do it for you. For others you'll have to write the migration code yourself.
Perhaps start here: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html
Like #Nielsbot said, there's a migration system that Core Data uses.
You can create new versions of your model and select which one to use. There's a little bit of code to change in your AppDelegate method where the persistent store coordinator loads the model to tell it to load versions. I'd suggest you read Apple's documentation on how to implement this at: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html
If you're just adding one field to a table then you can create a new version of the database. Keep the current one unchanged.
In one of the menus there is a create new data version or something.
Make the changes in the new version.
There are numerous tutorials about how to do this.
If you release an update that crashes the app then apple won't approve it so you will have to so this anyway.
I am trying to get this IndexedDB stuff working in a Metro (Windows 8) app, using JS.
I thought I was good, but then I ran the WACK tool a couple of times, just to see if I ran into any issues.
After these tests the IndexedDB.open call no longer opens my database (which has 7 entries in it) instead it fires onupgradeneeded, and gives me a blank (new) database (since I create an object store in the onupgradeneeded handler).
I did not change my version number, I did not change the database name. So I am guessing the applications domain somehow changed during the WACK tests.
Does anyone now how to get my database domain back?
One of the things the WACK test probably does is doing a fresh install of the app checking if everything goes fine. So when the app is installed for the first time you have to provide a creation of the database, this is done in the onupgradeneeded event.
I think you forgot to provide this, and that is why he creates a new blank database. Instead of a new database with the required structure.
I'm trying to track down a problem on our test environment. Previously it was set to use InProc Session State Type, but I've added in the SQLServer type for one specific Web App. I did this because we use the SQLServer type in our production environment and I want our test env to match as closely as possible.
However, after changing it to SQLServer I do not get any errors when trying to store unserializable data in session like I would expect. It works just fine, even though I would think it shouldn't. I'm a relative newbie when it comes to configuring this, but from the various tutorials I googled, I thought I covered all the bases.
I was wondering if there's any code snippets to verify which session state type an application is actively using.
Thanks
Ok, found it by accessing:
System.Web.SessionState.HttpSessionState.Mode
Was also able to look at the tables in the ASPState database to see sessions being added/removed.
Apparently it was just the test code we were using that we expected to break that was not behaving as we expected..