Community mailing list archives

Re: About Attachment File Location (again)

Anybox, Christophe Combelles
- 02/03/2015 03:37:03

Le 3 février 2015 04:08:15 EET, Phui Hock <> a écrit :
>I regret the best theorical solution is rarely the default in Odoo.
>is always dependent on the context and you should rather let people
>choose what
>is practical for them. Hopefully it's easy to migrate data from the
>storage to large objects.
>> LOBs:
>> - transcationals
>« transactional » means much more than a single word
>LOBs also :
>- are easier to setup
>- are more reliable
>- are replicable
>- are consistent (and not "eventually" consistent...)
>- can benefit from postgresql tools regarding backups, replication,
>> but
>> - bloat the replication stream
>You need to transfer the file anyway. At least, there is only one
>stream to
>manage. No need to set up an rsync or anything else.  Depending on the
>type of clients, saving binaries to database may be not acceptable at
>all. I have a client who is a media house and 90% of their files are
>several hundreds MB in size. One of their primary requirements is to
>have these files backup and accessible on their NAS-RAID. If the files
>are saved in the database, 

How do you keep a total sync between what is in the NAS and the ir.attachment metadata in the database?

>it would incur unnecessary database overhead
>every time the files need to be accessed or manipulated.

With the default 7.0 storage maybe, with the blob there are no more overhead than just reading a file from disk.

>For instance, we needed to generate previews and thumbnails for each of
>the known types. We also need to add watermark on-the-fly. These type
>of operations are easier and faster when files are saved on local

It seems easier in the first place (but not faster). It's easier to modify a file in the filesystem with a filesystem tool indeed, but it's harder to do it while keeping real sync with what is in the database anyway. And eventually I would bet it's easier in the long run to rely on the database security and transactionality.
It all depend on the importance you give to your data.

>Having these binaries saved on local filesystem also benefit from
>quicker streaming when served via web server such as nginx.

This is totally wrong, you can stream large blobs directly from the database do the browser, even PHP offers such features. And regarding small files they are supposed to be correctly cached anyway so they end up being never served by the filesystem nor the database.

>> - esay to browse by a human
>I'm not sure humans are good at browsing such SHA1 trees :
>│  ├── 57
>│  │  └── 57d4a8c7b652d6928d791c458cb04a246e3fb1ba
>│  ├── dc
>│  │  └── dcf00aacce882bbfd117c0277e514f829b4c5bf0
>│  └── ef
>│    └── ef2c882a36dbe90fc1e7e28d816ad1ac1464cfbb
>└── v8
>├── 35
>│  └── 358d08bafbecf102728c217bcc3eb0a24647443c
>├── 36
>While I agree these are not human readable, I don't think it is hard
>too to derive another filestore that overrides SHA1 filename with
>actual file name.

I believe something similar was done in old 6.1 or 7.0 modules that were abandonned due to their poor quality. Repoducing that with the filestore would make people believe they can use and modify it as real files which is wrong unfortunately, unless you maintain the sha1 filename and directory manually...

>Post to: