[DGD] DGD & MySQL

Fri Sep 19 17:15:34 CEST 2008

  So...  This may be an odd question, but, if you're going to handle your objects with SQL, why are you starting from DGD?  DGD already has fairly complex object semantics which aren't a great match for SQL's, it has a large set of operations you'd need to support, it has extreme configurability...

  Perhaps you want to start from some simpler flavor of LPC if this is your goal, or with some non-LPC language?  A lot of what makes DGD interesting, other than atomic functions, is its ability to limit stack depth and CPU usage in a sane way, and to recompile on the fly.  The last is available in a number of other languages (e.g. LISP, Ruby, Python) where you'd likely have an easier time writing a library to back MUD-type objects with SQL.  In fact, by writing a library in another language you could pretty much just write it so that you can recompile all MUD-type stuff on the fly, rather like DGD's "recompile LPC, but the server is constant per-run" approach.  Unlike DGD, you'd also have non-persistent objects too, it's true, but you'd also have the power of those languages, the community of those languages, etc.

  Where those same languages really fall down and DGD shines is atomic operations, especially in combination with the other features I mention above.  However, that's why mapping to SQL is complicated.  Because at one level it's "just" using transactions, but DGD has to deal with how files, network connections, its global variables, etc, all map to those transactions, while maintaining good performance.  That's the part that's not trivial.  Perhaps you should have a look at the DGD code (it's easily available) for a bit before arguing "it's trivial!" to people that have had a look at it and said it's really not trivial ;-)

--- On Fri, 9/19/08, Shentino <shentino at gmail.com> wrote:

> From: Shentino <shentino at gmail.com>
> Subject: Re: [DGD] DGD & MySQL
> To: "All about Dworkin's Game Driver" <dgd at dworkin.nl>
> Date: Friday, September 19, 2008, 5:02 AM
> Time for me to fess up.
> 
> I was figuring on using SQL of some sort as a way to
> replace DGD's
> internal usage of a swap file.  One of my side goals is to
> write an
> open-sourced version of DGD that us poor folks could use to
> cover
> server costs with donations (no economics or politics
> please, it's
> something better discussed privately).
> 
> Here's a few ideas I was bouncing around that are still
> in the design phase:
> 
> Have 1 table per object type.
> 
> Recompilation involves ALTER TABLE along with the
> renaming/removal/addition of new columns.  Basically, each
> variable
> has its own column.
> 
> Or, to have a single "master table" and multiple
> "slave tables", with
> the slaves retaining old, unconverted state that is only
> checked if
> the master table gives a no-show.  Meanwhile, background
> threads would
> be pumping the old stuff into their masters, with the
> appropriate
> swizzling upon upgrades.
> 
> As far as taking care of rollbacks...I believe a simple
> transaction
> that can be committed and/or cancelled upon demand would
> suffice.
> That is, after all, how MP's analogized.
> 
> On Thu, Sep 18, 2008 at 11:54 AM,  <bart at wotf.org>
> wrote:
> > I never looked at embedding sqlite or an sql database
> client, but I did look
> > at creating a tdbm or berkeleydb extension for DGD,
> and atomic functions and
> > transactions are where things become rather non
> trivial indeed :)
> >
> > To get this right, you'd want DGD to treat
> database objects as internal
> > variables so they can be taken into consideration for
> a commit/rollback. On
> > the LPC level this should work similar to a map tied
> to a dbm in perl (opendbm).
> >
> > The alternative is getting your extension involved in
> deciding on doing a
> > commit/rollback.
> >
> > Either solution means cutting deep into the internals
> of DGD in a way that is
> > bound to make tracking the development version of DGD
> difficult, and will
> > likely need a complete rewrite for DGD/MP.
> >
> > I think technically it is feasable, but considering
> the amount of work it
> > takes, I haven't proven enough of a need for it to
> myself to go on with it.
> >
> > As for having to store your lpc objects in such a
> database. that depends on
> > what you want your database for.
> >
> > One of the initial reasons for me to look at some form
> of database extension
> > is to be able to store very large key:value sets (for
> example for dictionary
> > lookups for a natural language parser or spell
> checker), not something for
> > storing lpc object state.
> >
> > Thinking of what I'd do with an SQL database..
> probably store data for a
> > 'galaxy scale' economy for my game :)
> >
> > At any rate, such an extension would have some
> advantages over all other ways
> > to accomplish this.
> >
> > Atomic functions and transactions can be integrated
> flawlessly
> >
> > It can get an answer to a request in the same
> execution round (provided your
> > database can provide an answer to a query in a
> reasonable amount of time or
> > you will stall your mud). SQL removes much of this
> advantage because many
> > things for which this matters can and usually are
> solved in SQL and handled by
> > the database server, but it will still make writing
> LPC code that talks to
> > your SQL server a bit easier.
> >
> > That said, an external daemon as Par suggests allows
> you to use a language
> > more suitable for talking to an sql database, and is
> technically a lot easier
> > to get right. Its also a proven solution :)
> >
> > Bart.
> >
> > On Thu, 18 Sep 2008 09:35:02 -0700 (PDT), Noah Gibbs
> wrote
> >> Sure, but that'll still take most of the same
> effort.  The hard
> >> part is integrating DGD features like atomic
> functions with SQL
> >> features like transactions, as well as more
> fundamental stuff like
> >> storing all your DGD objects in some kind of SQL
> format.
> >>
> >> --- On Thu, 9/18/08, Kurt Nordstrom
> <kurt at blar.net> wrote:
> >>
> >> > From: Kurt Nordstrom <kurt at blar.net>
> >> > Subject: Re: [DGD] DGD & MySQL
> >> > To: "All about Dworkin's Game
> Driver" <dgd at dworkin.nl>
> >> > Date: Thursday, September 18, 2008, 8:44 AM
> >> > Embedding SQLite might be another viable
> alternative to
> >> > MySQL too.
> >> >
> >> > http://www.sqlite.org/
> >> >
> >> > As they claim, self-contained, serverless and
> config-free.
> >> >
> >> > -Kurt
> >> >
> >> > > On 9/18/08 7:23 AM, Per Newberg wrote:
> >> > >> Greetings all!
> >> > >>
> >> > >> This is the first time I write
> here.. so hi! :-)
> >> > >>
> >> > >> My question is regarding DGD &
> SQL...
> >> > >>
> >> > >> Have anyone tried doing anything
> like this? Making
> >> > [My]SQL queries
> >> > >> from within DGD & LPC code?
> >> > >
> >> > > Unless you're really hungry to drop
> hundreds of
> >> > hours of work into this,
> >> > > my recommendation would be to design a
> new minimal
> >> > application-specific
> >> > > protocol that does precisely what you
> want and nothing
> >> > else and contains
> >> > > no SQL or table names, just your own
> logical
> >> > operations and references.
> >> > >
> >> > > You write a DGD client for the protocol
> and you write
> >> > a small Java
> >> > > server for it. The Java server takes
> requests from DGD
> >> > (localhost
> >> > > connection) and translates them into SQL
> through JDBC,
> >> > and mutates the
> >> > > results for DGD.
> >> > >
> >> > > This way you get a storage-agnostic
> interface (maybe
> >> > you'd want to
> >> > > switch to Berkeley DB at some point, for
> example) and
> >> > you don't have to
> >> > > deal with actual database connectors.
> >> > >
> >> > > Zell
> >> > >
> ___________________________________________
> >> > >
> https://mail.dworkin.nl/mailman/listinfo/dgd
> >> > >
> >> >
> >> >
> >> > ___________________________________________
> >> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >>
> >> ___________________________________________
> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> >
> > --
> > Created with Open WebMail at
> http://www.bartsplace.net/
> > Read my weblog at http://soapbox.bartsplace.net/
> >
> > ___________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd