I am generating some large files in my Rails application. Fortunately, they only need to be generated once. I would like to save these files to disk so that I don't have to generate them again.
Which directory in my Rails application is the most appropriate place to put application generated files?
Thanks!
If security of the files is not an issue you can put them in a subdirectory of public (for example, public/assets) which in your deploy script is symlinked to a directory in shared/public so that when you redeploy the files are retained.
If security is an issue, the solution is similar, though you would not want the directory to be web accessible. Instead you would use a controller to control access and serve up the files with send_file.
Related
I have a script which is using rspec tests for automation of the rails app. I don't want to put the file "automation.rb" in the spec folder or in the lib folder (don't want a gem for this code).
My question is: Can we have custom folders in addition to the standard ones in the rails directory structure.
Eg. a folder like automation in the root directory of rails app.
Yes, you can have any number of custom folders within your app structure.
The thing to be aware of here, is that if you're going to use code from these folders (why would you have them otherwise?), you'll have to load it.
To not mess things up much, you can add these folders under /app directory - anything defined there is automatically loaded in all environments.
As to scripts - indeed, you can just store them under the scripts folder in root directory - it's a common practice (at least I've seen it used in projects I have worked on).
Am using EngineYard to host my Rails 3.2 app. This application allows users to post images/assets. I save them in the public directory (using Paperclip Gem). Now, my problem is that - with a new deployment, I am having to manually copy over the assets to the CURRENT version.
Though, I could use AmazonS3, I still want to figure out if there is a way in EngineYard which lets me save/serve the assets from a different directory than the code, say /data/assets.
Please, let me know if you see any other alternate implementations too.
Typically your structure would look like
/data
myapp/
shared/
images
releases/
20120613000000
20120601000000
...
current (symlink to one of the releases)
When you deploy, you symlink public/images to shared/images and so your images always get stored in a non release dependant location.
I would encourage you to use something like s3: you'll make things a lot easier for when you want to host the app on multiple instances.
With the introduction of the new directory structure in 3.1 (i.e. app/assets/), should app images (logo, banner, icons, main bg, etc) still be stored in public/images or should they go into app/assets/images?
Someone mentioned:
I would be shocked if anything in
app/assets can be served publicly -
that wouldn't make sense from either a
security viewpoint or from honoring
the convention of the public
directory. Since you need these flash
files to be publicly accessible, you
should store them in public.
Valid point. Which brings me to the question:
Based on above understanding. What about the app images? If images such as logo, banner, main background, icons are considered public, why is there an images directory in app/assets?
Or should we still put these types of images in public/images. If so, what is the images dir in app/assets used for?
Note: I haven't looked at Rails 3.1 yet...
As far as I understood DHH's keynote, app/assets was introduced so you could structure your application in a better way. But there's nothing wrong with storing images in public/images. Thanks to Michiel for pointing out that public/images will no longer be with us in Rails 3.1!
The public folder will the replaced by the assets folder. That's the folder that your web server will point to. Files from app/assets, lib/assets or other places will be copied (images) or compiled (css, js) to assets.
That means that assets is now considered a build directory, and you shouldn't store anything there - you might even decline to put it under version control, and just have the server generate or copy the images and css and scripts when you deploy.
See also: http://blog.nodeta.com/2011/06/14/rails-3-1-asset-pipeline-in-the-real-world/
1) I am downloading datafeeds (xml) files from a URL to unzip/import them into the database. Where should I store them in the rails file structure?
2) How does the rails file structure work, can rails access the entire hosting environment? I basically mean, if I store my XML feed in /lib/files would I use that path in my models, or the longer full linux path?
Appreciate any advice!
You should probably use the tmp/ folder to store those temporary files
Its a good practice to always use the full path. You can get the rails root dir via Rails.root
Rails can access any thing that the user account under which the rails process is running, can access. ie: if you run the rails server process under root (which is not a good idea BTW), the app could access any path that root can access. This might of course be limited by whatever access control mechanisms in place by the OS(ex: SELinux).
ActiveScaffold apparently creates public/blank.html every time the server starts, even if that file already exists (so adding it to version control doesn't help). This is causing my application to fail to boot on Heroku, since they have a read-only file system.
Can someone please tell me how to prevent this behavior or work around it so I can deploy my app with ActiveScaffold on Heroku?!
In my rush to get this working I didn't even think to analyze the init.rb file within the ActiveScaffold plugin directory. Therein contains the require statement to a file containing the logic to copy files from the plugin's "public" directory on-server-load. Commenting out that functionality fixed my problem (after ensuring that I already had those files in their intended destinations).