Updated DDL for SQL backend

[Daniel Espinosa]

2006/10/28, Derek Atkins <warlord at mit.edu>:
> Quoting Phil Longstaff <plongstaff at rogers.com>:
>
> >> Nah...  Think of a KVP slot like a filesystem directory tree.  Each node
> >> can either be a File or a Directory.  The Slot Path walks down the
> >> tree (through KVP_FRAMEs) until you get down to a "file" node, a KVP_VALUE
> >> of some data-type other that KVP_FRAME.  Just because you don't have
> >> a KVP_VALUE of type "list" doesn't mean you can't (or shouldn't) have
> >> KVP_VALUE of type KVP_FRAME.
> >
> > Yes, but without lists, the analogy is each node being either a file or
> > a directory which can contain at most 1 file or directory in it.  I
> > question the usefulness of all of the directory levels.
>
> You're taking the "no lists" too literally.  A KVP_VALUE of type LIST
> is effectively a File with Multiple data contents.  It's NOT a directory.
> A Directory (KVP Value of type KVP_VALUE_FRAME) still contains a set of
> values!
>
> >> However...  You CAN model it as a flat table!
> >> Take a look at the existing PG Backend KVP implementation.   You can
> >> model it as:
> >>
> >>    text(32) object_id NOT NULL,
> >>    text slot_path NOT NULL,
> >>    enum(kvp_value_types) value_type,
> >>    ... values
> >>
> >> You can construct (and deconstruct) a full kvp tree this way.  No
> >> need to reference parents or anything like that.  The slot_path would
> >> be a string like "/A/B/C/D".  Each "/" implies a KVP_FRAME with "/"
> >> denoting the "root node".
> >
> > Fine, but without lists, isn't this equivalent to adding '/' to the list
> > of chars which can be put into a KVP node name?  Without lists, "/A/B/C"
> > and "/A/B/D" are separate independent nodes.  With lists, C and D are
> > children in the list "/A/B".
>
> Yes and no..  You can iterate over all members of a KVP_FRAME.   BUT
> this iteration is always done in RAM.  The DB only needs to treat a
> full set of slots as an atomic unit.
>
> So, yes, you, as the DB Backend, can think of it this way because you're
> always loading and storing the full data-set atomically.   In reality
> it's not the case, but you can ignore reality for your purposes.
>
> >> The only question with this approach is how you model an empty KVP_FRAME
> >> as a leaf-node in the tree.
> >
> > Yes, this works.  By adding 'empty' to the KVP type enum (at least in
> > the DB), you can model empty KVP frames.
>
> Okay...
>
> > Phil
>
> -derek
>

Are there any point to take apart the "internal functionality" and the
"DB work"?

Are we thinking about to use the power of the DB in data managing? Are
there a point where we can "change" the core in that way? and
implement a "plugin to import 'old format'?

Sorry, but I need to study some code before make sure about you're
talking about but, I don't want to try to implement the GC "internal
functionality" forcing the DB to that, without consider the power or
problems, when you use a DB.

Have you consider to implement this backend using GObject, and
implement a interface to QOF to avoid re-write the entry core, but
make the first steps to implement a new arquitecture in the Core.

-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (entrámite, pero para los
cuates: LIBRE)