vk-dbms / preview and call for Beta Testers

Hi All,

It has been over 6 months since I last mentioned my in world database project that was largely awaiting the release of MONO into the wild.
For the past month I have been extensively testing the underlying primitives and am reasonably sure that I have squashed the bugs and am now working on code optimisation.

I have not yet decided how to release the underlying code, for public use or to open source it, but the reason for this post is to show the database primitives available to the user and to gauge the interest of others in using the system.

I have created a Document showing the available commands and 3 example applications that utilise them.

All three examples are in everyday use at 2 separate venues, as part of the beta testing. The document is far to large to reproduce here in the forum so I have posted it as a publicly available Goggle Document.

http://docs.google.com/Doc?id=d79kx35_26df2pbbd8


here are the introduction and conclusion portions of the above, if it captures your interest, then please read the full document and feel free to pass on any comments, observations or suggestions you may have.

Introduction:

VK-DBMS is a Multi-Table database management system written for and in LSL, it has no dependencies on external databases and is totally embedded in the users script. The embedded code is called VK-ISAM-VM and will compile to LSL with 11920 bytes free and to MONO with 46324 Bytes free, the latter is the obvious choice for data storage but it still may prove useful as a applications environment in the former.
An understanding of the underlying ISAM-VM virtual machine is not necessary in order to use the dbFunctions described here. Example Programs written with VK-DBMS Follow this reference guide to show all the commands in practical use.

Conclusion:

This is a simple, yet powerful set of Database Primitives that allow us to store and retrieve data in a logical fashion. It has no dependence on an external database, so users neither have to code and maintain a web site for storage, nor depend on a third party to provide a service, all data functions are under the users control. It's uses, like the rest of LSL, are limited only by the imagination of the programmer and the memory constraints of LSL itself. In short, any application that uses lists may benefit from using VK-DBMS, the more lists an application would normally use, the greater the benefit, as all the list management code becomes redundant and is replaced by a common set of functions. It also eases the development of applications, as the designer can concentrate on the logic and structure of the data, without having to overly concern themselves with the format and and location of the data.


Summary of commands in alphabetical order:
string dbCreate ( string TableName, list ColumnNames );
integer dbDelete ( integer Row# );
integer dbDrop ( string TableName );
integer dbExists ( list Condition );
float dbFn ( string Function, string ColumnName );
list dbGet ( integer Row# );
integer dbInsert ( list Values );
integer dbOpen ( string TableName );
integer dbPut ( list Values );
void dbSort( integer Direction );
integer dbTest ( list condition );
integer dbTruncate ( string TableName );

Helpers:

integer dbCol( string ColumnName );
string dbError - Description of last Error encountered
integer dbIndex - Table Index pointer
list dbRow - user variable

If any application developers would be interested in Beta Testing the system please contact me personally.

this is interesting but how large a database can you have?
you said:
"LSL with 11920 bytes free and to MONO with 46324 Bytes free"
is that the storage limit?
this looks really cool tho i already have ideas but it depends on storage limits

Nice job!

I'd love to give this a try.

It is entirely within your script, so there are no magical memory gains, in this version , the free memory is what you have available to your code AND data. I have found, however, that rewriting scripts to use it results in smaller code and more storage.

this looks brilliant and almost tempts me to drop all work to give it a spin with creating something new

great work from what i saw from the example applications!

Sounds interesting, I can't wait to see the source... and optimize it

Dropped you an IM in world Strife.

Very,

Am working on incorporating your DBMS code into my application and came across a possible addition you might want to add to the production code (I will be adding it to the code I'm using). This is to provide a new condition to the dbExists/dbTest function, a case insensitive comparison. Not a LIKE as would want the value to be the same, but just ignoring the case of the string. From looking at your code I think the following, placed in the dbTest function would do the trick .. no?

...
else if("c=" == llList2String(cnd, 1))
{
    t_i = (llToLower(t_s) == llToLower(_trm(llList2String(cnd, 2))));
} 
...

might come up with a different sysmbol for the condition .. but you get my drift.

Shifting

It already has a conditional test for that if I understand you correctly.
try this sample code.

dbCreate("test", ["name"]);
dbInsert(["Very Keynes"]);
if(dbExists(["name", "~=", "very keynes"]) llSay(llList2String(dbGet(dbIndex)));

The above is basicaly an non case sensative ListFindList so it would be true for "Very Keynes" or "very keynes" or just "VERY" as it is not interested in position.

or are you specificaly after identical appart from case?

Very,

Yes I saw that conditional test (~=) but am after completely identical appart from case, thus this suggestion. Useful for example for a list of Voice commands, don't want the user to have to worry about case when saying in chat, but need to be able to find the command in the list. And if we add in that the list could be dynamic (read from a notecard) we now have two possibilities for case mixup.

In your example I would be inclined to have the card reader convert to lower prior to storing and have the litener convert to lower prior to comparing.

I tried to keep the core memory footprint low, so would rather avaoid adding conditionals.
If there is a need I could implement a LIKE clause, the code exists in the SQL version of this project, but it is about 10 times the footprint of the ~=, which I find covers 80% or more of the tests that LIKE is normaly used for.

Very,

Can't do the conversions on the read as I have it set up where a line in the note card contains multiple fields seperated by :, I then pass this to a generic function that splits the string into a list and inserts into the DB. Some of the fields are display text so can't apply an llToUpper or llToLower, and don't want to burden my code with breaking out and identifying each field.

In any case the code snippet I suggested was just that, a suggestion, and as I said not looking for a LIKE functionality at all, just a case insensitive equality comparison. I assume that the code snippet I posted would work?

Hi, yes, your code sippet looks good, and implement it if you wish, I can't actualy test it as I'm no were near my development environment
You could also bypass the built in conditionals entierly by controlling your own loop and doing your own test with the dbGet function.

Perhaps implement a flag of some sort. SQL ("automatically" does case-insensitive matches for certain character sets and collations.

I'd love to give your code a test location. I've been developing an app that uses a lot of data, and the sorting, storing, retrieving of that data is time/space consuming at best.

Your description sounds like a perfect to the problems I've been trying to tackle!