On Mon, Apr 20, 2009 at 3:06 PM, Matt S Trout <[email protected]>wrote:
> On Sun, Apr 19, 2009 at 01:17:07PM +0200, Francesc Romà i Frigolé wrote: > > On Sat, Apr 18, 2009 at 1:42 AM, Marc Mims <[email protected]> wrote: > > > I also removed DBIx::Class::UUIDColumns as a base class. I still 'use' > > > 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 look > 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
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
