[DGD] DGD & MySQL

Fri Sep 19 21:20:31 CEST 2008

Designing a driver that uses a database backend for storage is in itself a
very useful idea, and an approach that may work quite well. I'd personally
look at something a bit more 'low level' then an SQL databse, but both
approaches have their distinct advantages. 

My previous comments concerned adapting DGD to provide a way to interface with
a database from LPC code, not on designing a new driver that is based on a
database as storage backend. 

Wrt transactions and atomic functions, the problem is not so much doing the
actual commit/rollback, transactions will quite be able to do that for you.
The bigger problems are in deciding when to commit/rollback and in not having
race conditions between your database commits and the driver's internal state.

On Fri, 19 Sep 2008 05:02:45 -0700, Shentino wrote
> 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

--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/