/ 
DBIx-Jello-0.0001
/ DBIx::Jello

NAME

DBIx::Jello - stupidly flexible object storage

SYNOPSIS

# Where is my DB store?
DBIx::Jello->filename("/folder/filename.sqlite");

# create / get a class
my $class = DBIx::Jello->create_class( 'MyClass' );
# $class is now 'DBIx::Jello::MyClass';

# create a new instance of the class
my $instance = DBIx::Jello::MyClass->new();

# set params on the instance
$instance->my_param('value');

# get attributes out again
my $val = $instance->my_param;

# retrieve instance by ID
my $another = DBIx::Jello::MyClass->retrieve( $instance->id );
  
# search for instances
my @search = DBIx::Jello::MyClass->search( my_param => "value" );

DESCRIPTION

Class::DBI is faar too much work. What I really want is to just make up classes and their names, and to have tables dynamically created if I decide that I want a new class, and to have columns in the table magically created is I decide that I want a new attribute on the class.

I'm out of my tiny little mind.

PACKAGE METHODS

filename( [filename] )

Returns the filename of the SQLite DB we're connected to.

If passed with a parameter, connects DBIx::Jello to a SQLite database, creating it if it has to. If you want to connect to more than one database, you'll need to subclass Jello - different classes can connect to different databases.

Changing the filename after connecting is probably a really bad idea.

create_class(name)

Creates a new class that can be instantiated and saved

all_classes

returns a list of DBIx::Jello package names for all currently defined classes

SUBCLASS PACKAGE METHODS

Subclasses of DBIx::Jello that correspond to database tables will have the following package methods:

new( key => value, key => value )

Create a new instance of this class / row in this table. Any key/value pairs will be used as the initial state of the instance.

retrieve(id)
retrieve( key => value )

retrieve an instance of the class by ID, or specific key. Returns exactly one object, or undef.

search( ... )

Search for instances.

INSTANCE METHODS

Instances of subclasses of DBIx::Jello, corresponding to rows in the tables, will have the following instance methods:

id()

returns the (read-only) ID of the instance

get( param )

returns the value of the named parameter of the instance

set( param, value [ param, value, param, value ... ] )

sets the named param to the passed value. Can be passed a hash to set many params.

AUTOLOAD

DBIx::Jello subclass instances provide an AUTOLOAD method that can get/set any parameter. Just call $instance->foo( 'bar' ) to set the 'foo' param to 'bar', and $instance->foo() to get the value of the foo param.

LIMITATIONS

We have to back onto a SQLite database. This isn't inherent in the design, it's just that there aren't any portable database introspection methods. It's fixable.

It's completely useless in the real world. I'd be _amazed_ if your sysadmins didn't kill you on sight for using it, for instance. It's going to play havok with replication, for instance.

TODO

My short-term todo

Typed storage

I'd like to store the type of the attribute as well, to compensate for the fact that we've lost the use of the DB for typing information.

Ordered searching

This will be hard - SQL sorting normally can use the column type to decide on alpha or numerical sorting. We can't do that here.

Clever searching

We could expose the raw SQL interface, I guess.

Instance deletion
Table cleanup

I can reasonbly remove any columns that only contain NULLs. This might be useful, I don't know.

CAVEATS

In case you haven't figured it out, I suggest you don't use this, unless you're _really_ sure. It's good for prototyping, I guess. The interface is also likely to change a lot. It's just a Toy, ok?