[Coldstuff] genesis 1.1.11-pre1

Brad Roberts coldstuff@cold.org
Fri, 24 May 2002 17:55:02 -0700 (PDT)


Trying to interpret what you are asking:

Has anyone written code to allow accessing a sql server from coldc?

I haven't and no one has submitted a patch that does it, but it wouldn't
be terribly difficult to do a very simplistic implementation.  There's
obvious performance issues, however.  SQL query runtime is highly variable
and genesis is single threaded.  Some SQL engines have an async interface,
but neither postgresql or mysql does, I believe.

You could ignore the issue of performance and just rely on the user of the
interface to write 'good' queries that return in sub-second time frames and
hope that the frequency of use is low enough that the lag resulting from a
sql call isn't too impactful, but I don't think I'd be comfortable
introducing that sort of problem into the code base.  Yes, I know that its
already possible to lag the hell out of things with some of the existing
calls, but that takes effort to cause to happen, for the most part.  It's
/very/ easy to write a bad sql query that can take days to finish.
Imagine a table with 10k rows in it called foo.  Then imagine the results
of this query: select * from foo, foo, foo, foo, foo, foo....  The result
set from that is 10k ** (number of times you join with foo).  Simple
query, disastrous results.

To support sql engines that lack a clean async interface you'd need to
write an adapter of some sort.  Something that provided an async interface
to genesis/coldc and handled threading or whatever it deemed the right
approach for providing the async/sync bridge.

On the off hand you meant the question the way you asked it, no.  I've
never heard of anyone who's considered placing the genesis byte-code
compiler and interpreter inside a sql engine.  What would be the goal
there?  To alter the stored procedure language of the sql engine to access
and/or be coldc code?  Doable I suppose, though I'm not sure what the
difficulties would be (other than that it would be a BIG effort) or what
the advantages would be.  I'm sure it'd be interesting, but I'm pretty
sure you couldn't allow arbitrary coldc code to execute, you'd have to
limit the 'allowed' side effects to approach any sort of sanity.  Ie, the
results of a given select statement being run twice in a row are expected
to be the same (baring something else doing an insert/update/delete), so
the coldc code couldn't be allowed to do anything stateful.

As to MOO2COLD, never seen it, never used it, don't own it.

Did I answer your question anywhere in there?

Later,
Brad

On Fri, 24 May 2002 elh@astroarch.com wrote:

> Date: Fri, 24 May 2002 19:31:07 -0500 (CDT)
> From: elh@astroarch.com
> Reply-To: coldstuff@cold.org
> To: coldstuff@cold.org
> Cc: elh@astroarch.com
> Subject: Re: [Coldstuff] genesis 1.1.11-pre1
>
>
> Hi,
>
> Has anyone integrated Genesis into an SQL server? Or any thoughts on how
> hard that would be or where to start?
>
> Also, has anyone updated the MOO2COLD code?
>
> Thanks,
> Edward Haletky
>
> >
> > I've taken all the patches submitted to coldstuff to date and created a
> > pre-release tarball for any who want to test it.  I've done little more
> > than make sure it still passes the limited test suite.  There are no major
> > changes in here:
> >
> >   http://www.puremagic.com/~braddr/Genesis-1.1.11-pre1.tar.gz
> >   http://www.puremagic.com/~braddr/Genesis-1.1.11-pre1.tar.bz2
> >
> >   * fix BUFFER in BUFFER.  Use buffer_index which contained a fix
> >     not propagated to the previously duplicated code in op_in
> >     (Allen Noe)
> >   * Apply (with changes (Brad)) a bunch of MSVC patches (Robert Bradley)
> >   * Fix some missed regerror -> gen_regerror's (pvx at wmute.net)
> >   * Fix method access setting error handling (pvx at wmute.net)
> >
> > I haven't tested the win32 MSVC patches myself, and I didn't apply them
> > exactly as they were submitted so I'm interested in hearing if there are
> > problems.  I believe there's some set of files that Rob has that need to
> > be added on top of the tarball before it's actually functional.  Or
> > something like that.  I'm just supporting what I can without the ability
> > (or desire) to test.
> >
> > If anyone has additional bug fixes that should be rolled into this release
> > or even just bugs that you haven't reported or aren't included in this
> > list, please send them my way.
> >
> > Thanks,
> > Brad
> >
> > _______________________________________________
> > Cold-Coldstuff mailing list
> > Cold-Coldstuff@cold.org
> > http://web.cold.org/mailman/listinfo/cold-coldstuff
> >
>
> _______________________________________________
> Cold-Coldstuff mailing list
> Cold-Coldstuff@cold.org
> http://web.cold.org/mailman/listinfo/cold-coldstuff
>