* Perrin Harkins ([EMAIL PROTECTED]) [010206 22:43]:
> Hi Chris,
>
> I've been reading the docs for the last couple of days and it looks very
> interesting. It's great to see a well-documented open source project.
> I have a couple of specific questions, which I guess are really about
> SPOPS more than OpenInteract.
Hi Perrin,
Thanks for the doc comments! More work always remains....
> First, how much control do I have over what gets loaded when in objects
> with dependencies? For example, if I have an object with relationships
> to other objects, some of which are expensive to fetch from the
> database, can I defer certain parts from loading until I actually use
> them?
Nothing gets loaded until you do a fetch() on an object or on one of
its dependent objects. For instance, in the standard user/group way of
doing things:
# Fetch the user object
my $user = My::User->fetch( $user_id );
# None of the associated group objects get fetched until you ask for
# them like this
my $group_list = $user->group;
That said, efficiency hasn't been at the top of the list yet. (Some
basic caching hooks are there but nothing attached yet.) I'm following
Andy Wardley's example with the Template Toolkit -- make it right
first and fast second :-)
> Second, how hard is it to override the default load/save stuff in a
> SPOPS object in order to do some fancy SQL? I've had situations before
> with O/R mappers where I want to use some more complex SQL for
> efficiency reasons (optimizer hints, etc.) or to load a set of objects
> at once (like a tree structure). Is that possible with SPOPS?
It's not too difficult. The SQL stuff for DBI SPOPS objects actually
goes through two layers -- one dealing with more abstract notions of
'save()' and 'remove()' and the other dealing with more concrete
INSERT/UPDATE/DELETE statements.
The second one (SPOPS::SQLInterface) is quite flexible but at a lower
level which should enable you to do custom statements. You can do as
much or as little as you like -- passing a fully-formed SQL statement
with a list of values to bind does the right thing.
So if you wanted to modify how objects get saved but not removed, you
should just be able to override the 'save()' interface of SPOPS::DBI
and nothing else. But I haven't tried this yet :-)
> Finally, if I'm using a SQL database, what support is provided for
> evolving the data model? Do I have to change my schema and write
> conversion scripts every time I change an object attribute, or does
> SPOPS try to use some sort of "generic" schema?
It's actually much simpler than that. Since SPOPS doesn't save any
schema information in the database itself, all you have to do is add
the field to your database (with an 'ALTER TABLE' statement or
whatnot) and add the field name to the SPOPS configuration definition
in the 'field' key. Removals are the same. And datatype definitions
shouldn't require any changes at all, as long as the DBD supports
datatype discovery sufficient for SPOPS to bind variables smartly.
It's a more lightweight approach than Tangram or Alzabo but deals with
most of the issues I've run across in a few years of web (etc.)
programming.
> And just out of curiosity, are you familiar with any of the similar
> projects that others have worked on, like Iaido (formerly Iaijutsu) or
> Jellybean?
I've looked into both of them at one time or another -- OpenInteract
has been under construction for about a year and SPOPS (and ancestors)
more another half-year before that. I'm jealous of Jellybean's
self-sufficiency, of the cool apps built on Iaido so far and of the
clean model of both of them. I hope to swipe (with generous
attribution) as much as possible.
Chris
--
Chris Winters ([EMAIL PROTECTED])
Building enterprise-capable snack solutions since 1988.
