I created a web-survey application using rails. The administrator specify each survey sections, questions, validations and possible answers/types of answers in yaml config files.
For now, I load the yaml config files for sections and questions at each request (on each page). I know I can use cache to optimize database queries, but would it be faster to use cache also for reading yaml config files? And what kind of cache would you suggest? memcache, binary file, other?
Thanks for any help on this issue!
I think Knuth said it best with...
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
Unless its a problem, move on with your life. However to avoid being ranked down for snarkyness...
In this case, you could read your config files into Class constants to avoid File I/O when you need to retrieve the information if you really think it's going to be a problem.
However based upon your problem what you're probably trying to do could be done better with Backbone Forms but then you'd be adding complexity with JavaScript.
I would recommend not using yaml files actually, unless there is a very good reason for it. You should use your DB instead. It would be much more user friendly and easier to maintain if you used nested models with the correct associations. This railscast actually is almost identical to your situation.
Related
I couldn't really find an answer for this on the internet. I am currently developing a relatively big web application in Rails. And my locale file is growing rapidly.
My question is, does it matter if my locale file gets really big? If it doesn't matter, how does Rails handle this? If it does, what would be a good solution to this? I found in the rails documentations that you can name your files respectively to their language e.g. index.en.html.erb. But that would mean I'd have to edit each view for each language individually when a change has to be made.
Thanks!
Locales are loaded into memory when the server is started (not on every request). Rails handles all locales internally as one big nested hash. Therefore Rails does not care if there are one big or many small locale files.
What you need to consider: What works well for you. I had to work with an app with ~ 5000 locales once. I was very happy that they were organized into one folder for each language and splited into multiple files: One for every model or controller. The locales were clearly arranged and easy to find. Later we used a webservice to maintain the locales (webtranslateit.com) what also helped a lot when working with external (not technical) translators.
You can try to break up your locales file into separate files. More info:
http://guides.rubyonrails.org/i18n.html#organization-of-locale-files
I am quite new to Rails and I need to implement a project for my University. This project consists of a website that will use a binary file as database.
So I need to know a thread safe way to read and write this file, taking into consideration that the same file (database) will be used by multiple process (each time someone access the site, it should read and write data into the file).
Thanks in advance
There really isn't a graceful way to handle that. You're much better off taking a more traditional approach, with a SQL server like mySQL or PostgreSQL, which do basically that same thing.
Edit:
I didn't realize you could use sqlite in multi-threaded mode. That would seem to satisfy both requirements...
I need about 1,000 words to be able to be accessed constantly by my app. The reason I want it detached is so that down the line, I can dynamically change what those 1,000 words will be.
But I don't necessarily feel this requires a database injection. I feel a simple .yml file could work.
Is this a good practice? And if it is, what would be the best way to do this?
Is it ok to load the 1,000 words in a before_filter call ?
Don't think that architecturally this is the right call.
If those are to be changed rarely, then you can put them inside a constants class. If you plan to change them often, what you will do is write to file system and read from it which is exactly what every database does, but in a much much faster and optimal way then you could possibly write.
My two cents. Let us know how it worked out.
Do not use relational database unless you really need to. If your "words" are relatively immutable, can be accessed simultaneously without multithreadig concerns, you do not need querying etc - they are better off in some hash loaded for entire applications on startup
loading them for every reuest is not a good idea.
( this advice is not related to ROR )
my projects deals with a client / server structure where the clients provide status information via a soap interface in a periodically way. every request (1 per minuete) contains a complex stucture of stat us data.
status information is used by many views and instead fetching the information each time from database i store the data in a sychronized list.
are there better caching techniques in grails? are sychronized lists a good solution?
This seems more like a generalized question so I'll provide some generalized thoughts form my own experience.
Are there better caching techniques in grails? are sychronized lists a good solution?
There may be several layers of cache depending on what your dealing with. I don't believe bare-bones grails itself caches anything with regard to your question however; there are configurable options and plugins that allow you to cache everything from queries, domain classes, service calls, page fragment, images, css and just about everything else. Not to mention your database and other layers may have their own cache options.
Having said that I would avoid using your own caching techniques unless your dealing with a very specific issue where you know you can perform better than a more generic approach like a second level cache (ie EHCache).
If you do roll your own cache you'll want to be aware of everything else that might be caching the same content as well. Caching a cached object form a cached query is a tough one to debug.
If performance is your concern you should always do some bench marking before you change anything. To truly get the best performance out of anything you'll need to understand how it works. Grails, hibernate and spring work together on performance and this isn't anything I can put in few sentences but there are plugins that can help you understand what is going on beyond the scenes like JavaMelody.
Lastly, if you already built something that works and everyone's happy don't break it. :)
Probably a properly scoped service may help:
http://grails.org/doc/2.0.x/guide/services.html#scopedServices
Maybe a "session"-scoped service may be the thing you're looking for.
You may want to take a look at the built-in caching techniques: http://grails.org/doc/2.0.x/ref/Database%20Mapping/cache.html
A more detailed way is described here: http://grails.org/doc/2.0.x/guide/single.html#caching
Depending on what you want to cache, you may want to use Caching instances (to cache everything of that instance) or Caching Queries (where you only cache the result of one query)
As you can see in the second link, the config lets you use EhCache as cache manager.
I would like to use a delimited text file (xml/csv etc) as a replacement for a database within Ruby on Rails. Solutions?
(This is a class project requirement, I would much rather use a database if I had the choice.)
I'm fine serializing the data and sending it to the text file myself.
The best way is probably to take the ActiveModel API and build your methods that parse your files in the appropriate ways.
Here's a good presentation about ActiveModel and ActiveRelation where he builds a custom model, which should have a lot of similar concepts (but different backend.) And also a good blog post by Yehuda about the ActiveModel API
Have you thought of using SQLite? It is much better solution.
It uses a single file.
It is way faster than doing the serialization yourself.
It is zero configuration. Very simple to use.
You get ACID compliance, transactions sub selects etc etc.
MySQL has a way to store tables in CSV. It has some pretty serious limitations, but it sounds like your requirements demand something with some pretty serious limitations anyway.
I've never set up a Rails project that way, and I don't know what it would take, but it seems like it might be possible.
HSQLDB seems to work by storing data on disk as a SQL script that creates your database. It records changes in memory and a log file, and when you shut down it recreates a single SQL script again. I've not used this one myself.
HSQLDB doesn't appear to be one of the supported databases in Rails. I don't know what it would take to add support for a new database.