[Dbix-class] InflateColumn with objects external to the database (like InflateColumn::FS)

[Francesc Romà i Frigolé]

On Mon, Apr 20, 2009 at 3:06 PM, Matt S Trout <dbix-class at trout.me.uk>wrote:

> On Sun, Apr 19, 2009 at 01:17:07PM +0200, Francesc Rom=E0 i Frigol=E9 wro=
te:
> > On Sat, Apr 18, 2009 at 1:42 AM, Marc Mims <marc at questright.com> wrote:
> > > I also removed DBIx::Class::UUIDColumns as a base class.  I still 'us=
e'
> > > it for its get_uuid method, but inheritance was probably not the right
> > > way to accomplish that.
> >
> > Thanks for doing this, the code looks much safer to me now :)
>
> How about factoring out ::UUIDSupport ? I almost wonder if that's a useful
> non-DBIC class, Any::UUID or something ...



I understand your concern about having unnecessary dependencies, but is
there any module which could provide a UUID which is already a DBIC
dependency? I'm not aware of a UUID::Any module, in fact,
DBIx::Class::UUIDColumns  dynamically choses one of the following UUID
modules

  Data::UUID
  APR::UUID*
  UUID
  Win32::Guidgen
  Win32API::GUID

So, it seems it doesn't add too many dependencies. Maybe the code for
choosing an appropiate UUID module could be factored out of
DBIx::Class::UUIDColumns though.

The UUID is needed to prevent clashes between uploaded files. Otherwise if
two users try to upload a file named, say,  "pony.jpeg", the second one
would overwrite the first. I guess we could detect that and prevent the
clash by renaming the subsequent files "pony.jpeg.1", "pony.jpeg.2", etc...

But, I think that would lead to confusions: the user could be fooled into
thinking that the class preserves the name of the file, and later run into
problems when files "randomly" change name.

Because of that I think it is advisable not to factor out UUID suport into a
different module



> > maybe we should propose a path to DBIC::Row or DBIC::InflateColumn to
> spark
> > such discussion...
>
> You just missed 08100 for adding features. I'd say hang fire and let's lo=
ok
> at how to make this trivial in 09 rather than add extra stuff we'll need =
to
> keep compatibility with, but I'm open to being convinced otherwise.
>


Sounds like very reasonable advice :) after all our concern is not to be
dependent on the DBICs internals, but I guess 08 is not going to change much
now that work on 09 has started.

Francesc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20090420/1ff=
f187b/attachment.htm