DBIx::Jello - stupidly flexible object storage

NAME
SYNOPSIS
DESCRIPTION
PACKAGE METHODS
SUBCLASS PACKAGE METHODS
INSTANCE METHODS
AUTOLOAD
LIMITATIONS
TODO
CAVEATS

NAME

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?