[DGD] DGD & MySQL

[Shentino]

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
>