Forum: Ruby is ruby only usable for pictures not for documents ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F87d150876b608711d5fc8154a8038c9?d=identicon&s=25 Herman Müller (gotzbold)
on 2009-06-03 21:39
Hi Ruby-Community,

I searched the last days a lot for finding a plugin or tutorial for
storing documents (like pdf, doc, dox, with mime-type etc.) into the
database, the only thing I found was plugins or howtos for storing
pictures (attachment_fu etc.).

Normally when you try to develop professional solutions you have to
store documents like contracts  etc. and something else into the
database.

But it looks like, that RoR is only good for storing pictures, do
sombody knows howt to store *.pdf, *.docs etc. into the database? Maybe
with full-text-indexing?

Thanks ahead,

Regs

Herman
90a73d9875462aaa9fab2feffafbffe7?d=identicon&s=25 Ben Bleything (Guest)
on 2009-06-03 22:06
(Received via mailing list)
On Wed, Jun 3, 2009 at 12:39 PM, Herman Müller <dgwauss@web.de> wrote:
> Normally when you try to develop professional solutions you have to
> store documents like contracts  etc. and something else into the
> database.

Well, you have to store them *somewhere*.  I'd argue that the database
is not a very good fit.  You can't query against a blob.

> But it looks like, that RoR is only good for storing pictures, do
> sombody knows howt to store *.pdf, *.docs etc. into the database? Maybe
> with full-text-indexing?

Generally it's better to store the files on the filesystem and paths
in the database.  As for indexing, you'll need to devise a method to
extract meaningful data from your documents and store that data in the
database.

Ben
017e05d1a49ffa59ea03e149e7af720b?d=identicon&s=25 Chris Shea (chrisshea)
on 2009-06-03 22:30
(Received via mailing list)
On Jun 3, 1:39 pm, Herman Müller <dgwa...@web.de> wrote:
> Hi Ruby-Community,

Hi.

> I searched the last days a lot for finding a plugin or tutorial for
> storing documents (like pdf, doc, dox, with mime-type etc.) into the
> database, the only thing I found was plugins or howtos for storing
> pictures (attachment_fu etc.).

attachment_fu can store whatever you give it.  The examples for the
has_attachment method includes ones like: has_attachment :content_type
=> 'application/pdf'

> But it looks like, that RoR is only good for storing pictures, do
> sombody knows howt to store *.pdf, *.docs etc. into the database?

Ruby on Rails has no intrinsic issue with storing PDFs in a database,
or any intrinsic strength for storing images.  I'd suggest reading the
documentation for attachment_fu to see how to do it.

HTH,
Chris
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-06-03 22:35
(Received via mailing list)
On Wed, Jun 3, 2009 at 4:30 PM, Chris Shea <cmshea@gmail.com> wrote:

> Ruby on Rails has no intrinsic issue with storing PDFs in a database,
> or any intrinsic strength for storing images.  I'd suggest reading the
> documentation for attachment_fu to see how to do it.

Maybe we should ship Prawn with an Sqlite database?  ;)
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-06-04 00:11
(Received via mailing list)
On 03.06.2009 22:05, Ben Bleything wrote:
> On Wed, Jun 3, 2009 at 12:39 PM, Herman Müller <dgwauss@web.de> wrote:
>> Normally when you try to develop professional solutions you have to
>> store documents like contracts  etc. and something else into the
>> database.
>
> Well, you have to store them *somewhere*.  I'd argue that the database
> is not a very good fit.  You can't query against a blob.

A database gives you a few things which may be important for some
projects

- it is transactional, e.g. you can do safe updates in concurrency
situations and you can make sure that a set of changes is done
atomically.  This helps keeping application data consistent.

- you have all your application data in one place,

- which is especially useful for backups; RDBMS usually come with some
form of backup solution, some of those are even capable of doing hot
backups, i.e. while the application is active.

- professional databases come with a lot more features that can be
important for a business (replication, security...).

>> But it looks like, that RoR is only good for storing pictures, do
>> sombody knows howt to store *.pdf, *.docs etc. into the database? Maybe
>> with full-text-indexing?
>
> Generally it's better to store the files on the filesystem and paths
> in the database.  As for indexing, you'll need to devise a method to
> extract meaningful data from your documents and store that data in the
> database.

That extraction and indexing part can be done by some databases for some
document types (full text indexing, features for spatial data).  Of
course, you pay a price when you place documents in the database
(license fees, no direct access to docs) but one should be aware of the
options.

Kind regards

  robert
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-06-04 03:56
(Received via mailing list)
Ben Bleything wrote:
> On Wed, Jun 3, 2009 at 12:39 PM, Herman Müller <dgwauss@web.de> wrote:
>> Normally when you try to develop professional solutions you have to
>> store documents like contracts  etc. and something else into the
>> database.
>
> Well, you have to store them *somewhere*.  I'd argue that the database
> is not a very good fit.  You can't query against a blob.

The database is not a good fit for large binary files because databases
and
filesystems are architected and tuned for completely different
performance
envelops. Databases work best relating long lists of short data.
Filesystems
work best manipulating short directories of huge files.

Further, a web server can serve those files without bothering Ruby.
'nuff said!

Put your documents on the filesystem and store their paths in your
database. The
Rails plugin called Paperclip shows how to do this, with a system that
would be
very hard to improve on.
This topic is locked and can not be replied to.