Rails 5, best way to save an image to the database? - ruby-on-rails

So I just started learning rails, and am making my own CRUD app on my own just to get familiar with it.
Ideally the app will have some sort of "Post" that will have a form and an image that will be submitted along with it acting as the "Main Profile" image.
This main profile image will be displayed in a "grid" view on the index page. I've heard of paperclip for Rails....but is that still the best option in holding an image in the database? or is it better to host the image somewhere else? Im somewhat new to a lot of web-dev concepts.
Thanks!
(Database will be postgres on prod at least and sqlite during dev)

Storing images in a DB isn't a good idea - it is generally slow and will affect the DB performance.
I would recommend the Shrine file attachment framework, which is the most lightweight and, at the same time, most sophisticated of its kind.
You could read a very interesting article by Shrine's author with the comparison of different file attachment frameworks.

Related

How to update only images and text without having to override the whole solution

I have a very small e-commerce website(not launched yet). Requirement: users need to be able to change image and text content only (not the price). Images and text are saved in a folder at the server (no database for images). Based on my research, I still have not got better idea than possibly creating a WCF Restful service!! My Code are in GitHub and project is hosted in Azure. I am using ASP.Net, MVC-5, RESTful, OData.
Please suggest me possible best approaches with reasons, if you could.
Images and such are considered a BLOBs (Binary Large Object). Best practice for storing those on Azure is to use Blob Storage.
You can find step-by-step tutorial here:
How to use Blob storage from .NET
Next time when you deploy your solution, it will not override images and texts, since those will not be in solution folder.

Changing existing Core Data Image Store from Transformable to Binary Data/Allows External Storage

I am about to undertake the daunting project of converting my live (i.e. already on the app store for a number of years) app from Transformable to Binary Data store for images in Core Data.
I have many users with very large databases that store lots of images. This has really slowed down the Backup/Restore process, and probably caused some other behind-the-scenes issues as well. I didn't know any better when I set it up this way years ago.
How can I undergo this process so as not to lose even one of my customer's images? If it were just me and my own data, I'm sure I could get things working. But I want to be sure to do this properly, step by step, and I knew that this community could be a big help in that area. I really don't know where to start for the existing images.
Basically, I am looking for 1) steps to take, so as not to miss a beat. and 2) general advice, warnings, etc. in this process. I really need a clean migration when this version goes live.
Thanks in advance to anyone who can help.
One piece of advice: don't use "Allows External Storage", especially if you plan to use iCloud syncing with Core Data in the future. Reference: http://www.objc.io/issue-10/icloud-core-data.html
Instead, you might want to consider moving the images into their own files, and saving the URL to those files inside your database instead. You will have to work out how best to do the migration: lightweight migration is probably not an option if you go down this route.
Transformable data type is really just binary under the covers with some additional metadata. Have you tested a simple lightweight migration on an existing store? I suspect the migration would work and would leave the existing data in the store.
If you are looking to get the existing binary data actually moved out of the SQLite file then you are looking at something a bit more involved.
A heavy migration will accomplish what you are looking for but if the stores are large it may take took long and potentially not provide enough feedback for a good user experience. I personally do not use heavy migrations, ever, on IOS but it will accomplish your goal.
An export/import will also work. I generally recommend export/import when a lightweight migration won't work. It involves a medium amount of code but in the end you own the code, understand the entire process and can tweak it to your exact needs.

iOS app - complex UI with separation of complex data

I am planning on developing a data intensive application for medical guidelines, these guidelines will need updating every so often so there will be a requirement to update them myself as the developer. One option is to put the data in a plist but I find this approach quite tedious. I was thinking of using chunks of HTML and referencing the files in my application, this way they would be a lot easier to edit.
I am curious to know how the interface below has been generated or what options I have available to generate a similar interface, is HTML the best option here or native UI elements with either Core Data + Core Text or SQLite + Core Text? Bearing in mind that I want an easy way to update the data and the data must be available to the app whilst offline?
Bearing in mind that I want an easy way to update the data and the
data must be available to the app
I would go with plists. I think they are quite good to hold your data and to be edit by any person (non IT related person, with HTML they would have to be careful with tags). HTML files although ok, don't think it's as good as plists, since on the last one, you immediately understand the hierarchy if you structured it correctly, while on HTML is just a bunch of files. As for the view, I do think a UITableView with some custom UITableViewCells would do the trick (I find the interface a bit ugly to be honest).
I would go with SQLLite database, which you can frequently update from your server.
I have also created a medical app and oftenly need to update the data, so I designed it on SQLLite.
I check at program startup if a new version of the DB is available and if it is I'm downloading it on the App replacing the old version.
Just keep in mind that you need to keep a record in your App about the DB version it is running and whenever you update it you need to update the db version key on your App as well.
I would also suggest to create an editable version of the SQLLite DB in case you want to allow the users to store data to it, by copying the database from the app bundle to the users documents dir.

A place to store file ( Ruby on Rails )

I'm new to Rails, I wanted to make a website for uploading files: music, videos, pictures, text. What is a better way to store files? I've read about different methods: Database, as a file, Amazon S3?
There will be a lot of files around 1 kb to 20Mb each.
Thanks!
Storing files in a database is not bad, per se. It depends on the kind of database.
Storing files in a relational database is not view as a good practice by the reasons explained by bassneck.
But there are other kind databases that are specifically designed to store any kind of data, in a non-relational way, for example files of any kind. The answer of Dhruva highlight that, MongoDB is pretty good and its support for storing files using GridFS is awesome.
GridFS is very good, for example it can stream only parts of a file, pretty useful for video.
In your specific case – many small files of many kinds of data – GridFS is an real option. I use Heroku & mongohq.com and they work like a charm.
I don't think there is a right answer for that. I use heroku, so my only option is Amazon S3 (which has free quotas for the first year) and I'm pretty satisfied with it. I use carrierwave gem for uploading files and it's really easy to use. I really prefer it over Paperclip.
If your hosting provides a lot of space and bandwidth then you could give it a try.
But for the database, I really don't like the idea of storing files in it.
Updated
Reading a filename from the table should be faster than reading the file itself. The bigger the DB, the longer it will take to make a backup. And if you take heroku for example, you only get 20gb for a shared db. That's not much if you're gonna store 10-20mb files in there. Moving project to another hoster might be easier if you store files in the DB. But if you use an external service (such as S3), there would be no difference for you.
Amazon S3 integration on Heroku is relatively easy to setup and get working with the paperclip gem. Heroku has some documentation on how to get this up and running.
Take a look at their documentation and see if this is the kind of thing your looking for.
http://devcenter.heroku.com/articles/s3
I will suggest you to also check out & consider MongoDB GridFS - http://www.mongodb.org/display/DOCS/GridFS+Specification. My experience with GridFS has been good. I cannot give you a comparative analysis with the other options, however I would like to know the same.
I would recommend you use amazon s3 to store your files. It is the best.

Rails CMS: static files or database records?

I'm trying to figure out the cut-off with respect to when a "text entry" should be stored in the database vs. as a static file. Are there any rules of thumb here? The text entries will be at the most several paragraphs and have links to images and tables (and hyperlinks to other text entries). Some criteria for the text entry:
I'm thinking of using DITA as the content format
The text should be searchable
If the text is revised, a new version will be created
thanks in advance, Chuck
The "rails way" would be using a database.
The solution will be more scalable, therefore faster and probably easier to develop with (using migration and so on). Using the file system, you will have to build lots of functions on your own, that are already implemented for database usage.
You could create a Model (e.g.) Document and easily use existing versioning systems, like paper_trail. When using an indexed search, you can just have an has_many relation enabling you to realise the depencies between the models (destroy a model means to destroy the search index).
Rather than a cut-off, you could look at what databases provide and ask yourself if those features would be useful. Take Isolation (the I in ACID): if you have any worries that multiple people could be trying to edit an entry at the same time, a database would handle that well while you'd have to handle the locks yourself working with files. Or Atomicity: you might want to update two things at once (e.g. an index page and an entry page) and know they will either both succeed or both fail.
Databases do a number of things beyond ACID, such as taking advantage of multiple datatypes, making querying easier, and allowing for scaling. It's a question worth asking since most databases end up having data stored in a bunch of files on disk. Would you end up writing a mini-database if you used files yourself?
Besides, if you're using rails you mind as well take advantage of its ActiveRecord functionality, and make it possible to use the many plugins that expect a database.
I'd use a database for even a small, single user rails app.

Resources