The framework will be changing in perpetuity and it cares about performance
so being able to specify files is a given.

At the same time projects that rely on the framework need to be able to do
the same thing without being screwed if the framework needs a new "slot".

If *Dbs is only used to point to locations where new objects are created
how does the database logic work for objects that already exist? How does
it know to look for X in file Y if it doesn't use the pointers in *Dbs?

I'm trying to understand why no gaps in the file numbers are allowed and if
it is possible or how much work it would be to make it so?

On Sun, Sep 8, 2013 at 2:09 PM, Alexander Burger <>wrote:

> Hi Henrik,
> > number than the dbs call has resulted in, thus causing a "gap", it seems
> > like this is a no no.
> Right. The file numbers must be continuous.
> > (dbs
> >    (3 +Server)
> >    (3 (+Server ip)))
> >
> > (dbs+ 100
> >    (4 +Entry)
> >    (4 (+Entry tag)) )
> > ...
> > Works fine if 100 is changed to 3 though.
> >
> > This is causing problems for me with the extended framework I'm working
> on,
> > the framework is loading its own E/R structure with a dbs call. The
> thought
> > here is that projects that use the framework will first load it and its
> > E/R. Then the project code will add its own E/R through a dbs+ call.
> This is fine, and the reason for 'dbs+'.
> However, the data structures created by 'dbs' and 'dbs+' are mainly used
> for creating _new_ objects, and have no influence on existing objects,
> so that changing them for existing databases is not a very good idea and
> may cause extensive (re)work (as I explained in my last mail).
> > The crux is that since the framework will always be under development it
> > might need more database numbers, I was hoping that I could pick some
> > arbitrarily high number like 100 as a rule for projects to use in their
> > dbs+ calls to ensure that there would never be a collision.
> As long as the framework is under heavy development, I would not care
> too much about '*Dbs', since performance (optimal distribution of
> objects across DB files) is not an issue.
> Still you can keep it dynamic in a convenient way, if you keep in mind
> the above restrictions and caveats.
> I would write:
>    (dbs
>       ... )
>    ...
>    (dbs+ (inc (length *Dbs))
>       ... )
> ♪♫ Alex
> --

Reply via email to