ID:753273
 
Keywords: sqlite
Redundant
Applies to:DM Language
Status: Redundant

This feature has already been implemented, or is already achievable with existing methods.
I'd like my game(s) to be able to store a nontrivial amount of data in a format somewhat more manageable than plaintext flat files, but setting up a full-fledged MySQL server seems like deer hunting with a howitzer, honestly.

I know BYOND already has native MySQL support. What would really fit the bill and allow for low overhead for people that would rather run leaner when possible would be support for SQLite database files. Is this by any chance already in the cards?
MYSQL Native? it's not native .... it's a library...

You could use a DLL file for SQLite honestly all the tools are available setting up a MYSQL server takes 4 seconds and managing it with PHPMyAdmin makes it 50 times better...

Grab a free PHP + MYSQL host and your off they do it all for you .... or if you wanted to do it local just simple install XAMPP

XAMPP has variants for Windows, Linux, Solaris and Mac. To top it off it's free.

TL;DR - It's a waste of precious time for Tom and Lummox Jr when the tools are available for you to do it yourself.
This would already be possible if you use my dmjava library to attach Java to BYOND. You can then work with sqlite through Java, exposing an API to BYOND so you can communicate back.

The additional benefit of this is that you can work with prepared statements, which allows you to prevent SQL injections from taking place in your game.
SQLite is a fairly pragmatic technology to apply here, so the feature request does make a fair amount of sense.

Probably the better approach might be to flesh out fuller ODBC support instead, allowing BYOND to natively support a range of database engines, embedded or otherwise. This gives you a nice choice of low, mid and high range (and consequently setup) engines, with a fairly standard instruction set.

OP: Any thoughts on ODBC versus a native SQLite implementation?

ATHK: MySQL statements are implemented in the language natively, this is what Dantom.DB and similar call onto. If you check out the library, there's a bunch of undocumented built-in procedures like '_dm_db_connect()' etc.

JBoer: He can, but then he adds Java support as a requirement for install, and of course the setup of jvm.dll and company, and requires trusted mode hosting. I'd dare-say for a guy looking for a lighter-weight solution than MySQL RDBMS, adding the java platform, upping the world security requirements and adding install steps is probably not the approach he'd like to take.
ATHK: I was not saying that setting up MySQL is difficult or beyond my ken; only that it is overkill, and a resource-heavy, cross to bear for some nontrivial, but not mountainous, amount of data storage. DreamDaemon occupies ~170M of virtual memory on my system. Adding SQLite support to BYOND would be a negligible increase, as its entire raison-d'être is to be a lightweight solution. A MySQL server nearly doubles system resource usage (one small MySQL server I run occupies ~135M of virtual memory. This would nearly *double* the memory footprint. Not acceptable.

JBoer: See below.

Stephen001: ODBC would, of course, be an ideal solution as it would be a (presumably) lightweight bridge to _any_ database engine. You predict rightly when you day rollout of a big, weighty Java stack would raise similar issues to me as a MySQL server, but it might serve as a stopgap pending either native SQLite or ODBC implementation.
BYOND does support DLL/shared object calling, so you may want to wrap sqlite a little more directly, and avoid the java stack, if your C/C++ is up to it.

http://www.byond.com/docs/ref/info.html#/proc/call
In response to A.T.H.K
A.T.H.K wrote:
MYSQL Native? it's not native .... it's a library...

A bit of a tangent, but,
Nope. It is native. The library just gives us the method of accessing the BYOND Core's inner functions.

If you look through the BYOND Core (byond.dll), and the dantom.db library, you'll see things such as _dm_db_new_con(), _dm_db_connect()

This is also seen in dantom.zipfile, with "_dm_interface".

Icon/sound procs/vars are also soft-coded in a file called stddef.dm, which is tied directly into the BYOND core, where you'll see things like
icon/proc/Width()
return _dm_icon_size(icon,1)


Pretty much anything that starts with _dm_* is an accessible but pretty much unknown/secret function.

Now back on topic...I'm sure if BYOND already has the functions to deal with databases internally, a library could definitely be expanded/created to include this request.
I'm fairly biased in regards to this conversation, but, yes, @Stephen001, it's not that we can't write the requisite C bindings for our project. It's that it would be nice to not have to. SQLite is perfect for the sort of scale that BYOND games tend to be, and it has the great benefit of being "just files;" moving it around is as simple as copying the databases around with the rest of your BYOND payload.
Definitely, plus there's some complications on the hosting with DLL calling requiring trusted mode execution from the BYOND world also.
I'd like to make it so that one could specify trusted dlls in a special section.

The DB implementation is pretty generic -- the mysql "support" is really just looking for the dll and passing info to the protocol (no built in mysql code), so it shouldn't be a big deal to do the same thing for sqllite, postgres, etc. Ultimately I'd like to just move the db part to its own independent piece so that users could just write these wrappers themselves.
Both of those are very nice things to hear indeed, thanks!
LordAndrew resolved issue (Redundant)