Torque DB (possibly moving to C++)

#21 @Stephen - you have a point... maybe moreso porting my torqueScript database to c++ and making it work with the existing databases... all with script accessible commands and callbacks for easy integration into Torque...

a sort of middle man to simplify translation from script manipulation to data storage

though I like your idea of a step by step guide in setting up a database and connection...

#22 @Michael: very good to hear, was thinking around $20 just a return on the work put into it. Definately was thinking of implementing it with TGE, though a lot of the features wouldn't take much chance, considering they are torquescript and torque specific vs TGE/ T2D specific (since it deals with data vs rendering/physics/ etc )

btw very good to hear your honest opinions

#23 @Stephen: I do think we were thinking somewhat different things... though I like where you were comming from as well and its all linked...

I'm thinking more of a local database that can encrypt data for multi or single player... vs the data that needs to be sent to the server (though can create an easy integration with that as well)... for examples... database to store things vs doing
$gameData::bases = 10;
$gameData::maxInventory = 32;
etc
etc

that way data can be accessed in a centralized database... also with special editing tools a developer can edit them real time in engine and see them real time in a nice graphical display... maybe heavy customization available for the tools as well

#24 My .plan

This may help you a bit more Matthew, on understandind the direction I intend to take w/ TorqueDB

#25 The plan was very helpful, thanks!

#26 Well figured I'd throw it up... submitted my Torque DB + Journal System as a resource last night... haven't had the time to document it like i wanted to, but I have a whole lot of comments in the code, as well as a bunch of debug echo statements, all the echos have

if($debugMsg::journalDebug)

so if you trigger
$debugMsg::journalDebug = true;
in the console it will trigger the massive ammount of debug messages...

the journal system is included and I did manage to get the time last night to organize all the files better (vs a single 62KB file lol)... so the database files are seperate under different folders (cryptically named "journal" and "database" lol) as well as under different namespaces

Journal::
and
TorqueDB::

so at least thats orderly... so the journal front end isn't directly tied to the TorqueDB anymore...

I submited it with instructions to modify the guiMessageVectorCtrl with paths to Torque... I might need to submit another version for T2D, after I test it in T2D since I haven't yet... though the TorqueDB is co mpletely script driven that will work with any...

#27 I could not find the other post, I have install TorqueDB with TLK 1.4, I receive this (0): unable to find function journalDebug in the console after type this journalDebug();

I have try the following too

journal(); (0): unable to find function Journal

#28 In my spare time I am a postgres DBA , for a very large project .

Working out the specifics of the database connection should be something like you see in Perl's DBI module, a generic interface to x database to flatten out the API.

You then implement a base set of driver classes to each database product, while maintaining a consistent API to the application, a middleware layer like this would be more powerful than building a database from scratch In my opinion, then as a project grows and sqllite is no longer an option, the code doesn't have to be munged to provide postgres, mysql support, then later on, a simple change to the connector class is all thats needed to have native oracle support, etc.

The real advantage would be fixing this to torqueScript data types, you can then build class functions for your application to do the magic, while removing the overhead of everyone reinventing the wheel for database x,y, or z. Since the majority of these are open source databases, and the client code is open source, building the drivers should be fairly painless.

Like I mentioned I would look at how the DBI perl module pulled this off, its probably one of the most powerful and simple database framework api's out there. (in my opinion)

--Rodney