[DGD]serialisation/deserialisation of mixed data.

[balduin at uni-paderborn.de]

> Howdy,
> 
> > > Are you sure you want to store LPC datatypes wihin a mysql database,
> > > redoing what's already solved in DGD? :)
> 
> > yes ... since i need the search abilities of the database and expect
> > a lot of documents/objects if I ever come to the point to test the 
> > system. One part of the system will be (is) a html server and to achieve
> > link consistency every single bitmap has to be an object.
> 
> 
> If you are used to writing LPC, there's a fair chance that it'd be quicker
> to write a SQL*Net implementation than to write these kfuns in C. I don't
> know how proprietary the protocol is, but SQL and the DB functionality
> shouldn't be too hard to do?

Well it's not the problem to retrieve the data. I wrote some kfun wrapper
functions to access the mysql - C API with lpc. The problem why i want to
store dgd-objects in the database and not in the state-dump of dgd is the
limited number of objects dgd can handle, 64k seems to be a lot, but from 
Xyllomer i know that at reboot time (after 24h) we usually have about 20k
objects.  If I use a state-dump reboot won't help a lot to decrease this 
number and i'd be limited to about 10k Documents or even less, if I assume
that modern html pages consist of a lot of subdocuments e.g. pictures.
This is a lot for a single class, but even the document server of our 
workgroup at my university has about 10k documents. Not talking about
links, personal annotations and such stuff of the students. This forces
me to kick objects out of memory if they are not used for a period of
time which imposes a part of the problem i described, and makes the
state-dump useless for me.
> 
> But, do you even need SQL? Do you have clients that specifically use it?
> If not, DGD is a splendid database, and of course it is a simple thing to
> associate searchable/indexed entries with each piece of data. If you using
> SQL simply because it's easy, you may want to question this assumption.

Another point for me to use an SQL database, is the possibility to retrieve
and access the data through other means than dgd. Reorganisation, consistency
and such stuff can be better maintained if I don't try to do the database
stuff completely on my own.

Ludger
(balduin at uni-paderborn.de)

p.s. I won't put the mysql kfuns on a ftp-site for now, at least not
until i am a bit more satisfied with the implementation. But if you 
are interested in a copy you can have one. Btw. a SQL*NET implemetation
in lpc would be interesting, since this would allow for non blocking
database access. Currently dgd has to wait for the results of the database.

List config page:  http://list.imaginary.com/mailman/listinfo/dgd