* Tony Bowden ([EMAIL PROTECTED]) [010912 05:36]: > On Tue, Sep 11, 2001 at 04:14:55PM +1000, Robert McArthur wrote: > > Following on from the Class::DBI, is anyone using SPOPS inside/with > > TT? I know there's OpenInteract (hi Chris!), but SPOPS seems to be > > Class::DBI with a some (significant) extras. Or am I just confused :-) > > I've had a brief look at SPOPS but don't really know it ... > > As the new maintainer of Class::DBI, I'm obviously open to suggestions, > but I'm coming more and more to view Class::DBI not so much as a way of > serialising objects to a database, but to easily represent a database > in objects. > > Slightly nit-picky perhaps, but I think it's an important distinction. > > Many of the other 'persistence' models seem to be more for people who > don't want to have to think about database design and query optimisation > and complex relationships etc, but who want to store their objects' data > somewhere, and don't have an OORDBMS to hand, just a 'normal' one.
Hi Tony, Not that I want to get in a big comparison -- the doc that Dave Rolsky has put together at http://poop.sourceforge.net/ does a great job of that -- but since you said you don't really know SPOPS: - One of the main focuses of SPOPS is to get retrofitted onto existing data: it doesn't require a specialized 'object database' or even additional fields - SPOPS liberally borrows from other modules, like Class::DBI with lazy loading of object properties, object relationships (has_a and links_to in SPOPS parlance) and general behavior - Also similar to Class::DBI, you don't have to write any code to use straightforward objects, just create a configuration file or hashref - SPOPS implements integrated per-object security using a fairly simple user/group management scheme - SPOPS extends the idea of persistence by allowing developers to step in at certain points of the process (pre/post fetch/save/remove) and give behaviors to entire classes of objects as well as manipulate the classes that are generated from the configuration files. - Lots of other features -- iterators, GDBM and LDAP datastores, ... I think there are lots of ways to make object persistence work and plenty of space for different modules to spread their wings. The idea of 'one true persistence scheme' isn't very Perlish, IMO. (Not that you were saying that, it's just seems a natural progression of comparisons like this.) Anyway, I look forward to stealing^H^H^H^H^H^H^H^Hborrowing more features from Class::DBI in the future ;-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
