[Dbix-class] RFC: InflateColumn::FS

[Marc Mims]

* Moritz Onken <onken at houseofdesign.de> [081004 07:30]:
> What happens if someone changes the primary key? This is likely if you
> don't use auto_increment but characters. I guess the file cannot be
> found because the SHA changed.

In my own usage, the PK would never change, so I didn't have to consider
that possibility.  I did realize that might be a requirement for others,
so I added a TODO test for it but haven't implemented that feature, yet.

> Why didn't you store a random SHA-string in the file column and name
> the file using this string? This way the filename will not change if
> you  change the primary key.

Historical.  My original implementation was the IC::FS.  IC::FS::SHA1
was an afterthought.  In IC::FS, the filename is not based on the PK
value and is trivial to derive.  So, I liked the low storage requirement
of 1 or undef for the file column.  I carried over into ::SHA1.

Your idea is much better, though.  I can think of several advantages to
having the filename stored in the table.

I'll reimplement and post an update.  I'll have this in svn as soon as
mst has time to arrange it for me.

> There is another argument for doing so. If you update the file the
> filename will not change if the primary key(s) stays the same. A
> browser which  caches the file will not try to fetch the file again,
> because the filename  didn't change. If you would create a new random
> filename each time the file is updated you won't have such a problem.

Yes.  Even more reasons.

> Another thing which came to my mind is that you create a subdirecty of
> the two first characters of the sha string. This makes 256
> subdirectories (for SHA-hex).  But if there are hundreds of thousands
> files it makes still a few  thousands per directory. I'd prefer a
> config option where I can set the depth of the directory tree. Or I
> could overwrite _fs_column_storage myself :-)

I had considered the need for this, but hadn't given much thought to how
it.  As a start, I can factor out the directory naming functionality so
it can be overridden without having to duplicate the file naming code.

> I hope you understand what I'm worried about :-)

Definitely!  Thanks for the input.

BTW, what do you think of the module name?

	-Marc