LSL Database Access

If a standard US$11.95 web hosting plan can give its users 50MB of MySQL database storage, why can't LL give premium avatar accounts some MySQL database storage?

Say 10MB-20MB for all premium accounts, and then have plans for more space if somebody needs more space?

This is a real need for LSL projects that are stalled because we have no database access whatsoever. (external soulutions via XML-RPC or email don't count)

of course they can. they obviously just don't want to. that's a whole other story. i'm sure they've talked about it and have good reasons. i'm equally sure that they'll post them here in time.

I can think of several reasons:

- It would be an administrative nightmare
- I would hazard a guess that far fewer than 1% of people in SL would even begin to know how to optimize an SQL query. Not many more than that would even know where to begin writing one.
- Backups? Restores? Setting up a truely effective backup plan for a database requires intimate knowledge of the nature of the data stored therein. Either that or a top-notch DBA that can watch the activity on the server all day long and make determinations that way.
- Why MySql? Personally, I'd prefer SQL Server. I'm sure others would prefer Oracle, DB2, PostGreSQL, Sybase, etc. LL gets around this debate with LSL because it's their own, unique language. I'm sure Cory has enough headaches with LSL and all of our griping without taking on the additional headaches of SLSQL.

RPC, if it all worked and was reliable, gets around all of these problems by offloading all of the responsibility onto the individual user.

i think there are hosting places that sell JUST a mysql spot.

if there was enough demand i could maybe get something worked out for sl users with small payments, possibly in Lindendollars.

i'm willing to rent access to an sql server for a reasonable amount of lindens.

I know for a fact that a couple of people already have projects in the works along these lines, myself being one of them.

I started a thread in the scripting forum several weeks ago about defining an open standard SLSQL language, that could be used with either of the RPC methods to pass queries into the database, and also define the results format. Nobody seemed interested in helping to develop an open standard, so I'm developing a proprietary standard instead, for use with the SQL Server service that I'll be offering.

Note: The whole point to the open standard was to solve the "Which database?" problem, and leave it up to the service provider to build a processing/conversion engine to convert SLSQL into the appropriate, optimized version of SQL for whatever server platform they're using.

It'd be pretty easy to add.

You'd make a table something like as follows (datatypes illustrative rather than optimized):

create table userdatabase(
   ownerguid varchar(64),
   key varchar(64),
   value varchar(1024)
);

Then you either create a view on this, or do it programmatically (my SQL syntax is a little rusty):

"create view userdataview select * from userdata where ownerguid = '" + sOwnerguid + "';"

Now when a script reads or writes to this table, it only sees data that belongs to its owner.

Of course, there are examples where you'd like your data viewable by other people who now own your script, but the above implementation is fine as a first approximation.

Later evolutions could include providing a view on the data of the script's creator - rather than owner - and / or provide methods to transfer data from one user to another.

Azelda

Like I said, XML-RPC and llEmail solutions aren't good enough. The recent, and happened tonight again, problems with llEmail will show that it's not feasable to run reliable databases where you have to rely on the SL<->RL links.

We need in-world, persistent database storage. I don't care if it's MySQL, SQL, Notecards, something simplier, whatever. We need the ability to store data. Some sort of database. Cheap Internet accounts in RL provide it. SL should be able to too! We have database access right now with objects, textures, etc. We just need database access from LSL scripts!!!!

Then does it not make more sense to harp on them to fix email-RPC and XML-RPC (and complete XML-RPC) to the point where they're usable and reliable, rather than harping on them to add a new feature that will be borked, broken, or otherwise unusable 10% of the time?

No, it doesn't. And I don't notice avatar animations, a new feature, broken 90% of the time. Or music streaming. Or Automated auctions. Or Set Primitive Params. Or faster inventory loads. That's just plain silly to make a statement like that.

What kind of B.S. is it to deride a feature somebody wants by saying that it will be "borked, broken, or otherwise unusable 10% of the time?".



That quote should make it perfectly obvious. This would be a threat to a service you want to provide.

Several people have been asking for persistent storage long before XML-RPC.

Out-world solutions are not the answer to in-world problems. They are cool, but we need stuff in-world!

So long as we're wishing, I'd like a pony too.

And teleports that worked reliably. And for Pendari to have an avatar instead of a black hole, and prims that didn't drift. And a scripting language that didn't subtlely change every release in undocumented ways. And consistent rule enforcement. And groups that actually worked. And maybe a second pony or that big elepehant over there.

You may say I'm a dreamer....

This isn't a dream, or some silly paradoy thread, but a serious request. Lots more projects would be realized in SL if this capability existed.

Any, and I mean any external link from SL to RL will always have problems. Down servers, problems like we saw with email, etc. You can't through two systems together and expect them to have anything near what you are even suggesting inworld datastorage would be.

You are being backwards. XML-RPC and email will always be inferior to anything inworld. If the world breaks, then everything breaks. If the Internet, a router, your server, your database, some email server along the way, some users prim experiment clogging up the email system, etc can cause problems with external solutions.

I'm sorry if you read me as mocking your request, Hank, as I am in total agreement with you.

My point was that "feature requests" seem to be essentially meaningless at present as LL has some plan, but they are not disclosing it nor providing feedback on feature requests. It is the belief of some (not necessarily me) that they don't even seem to read these any longer. All of the things that I mentioned (minus the pony) have been requested with good cause to no avail.

Again my apologies, Hank.

Agreed. I was thinking the same thing just awhile ago. No apology necessary.

or at least a tunnel to some site that offers db hosting. i'm sure the db company would love it.

i'm talking sl<->db hosting. the communication layer could be hidden, and only the api for the db calls themselves could be made visible.

You mean like how RPC is now?

RPC will always have a high risk factor due to the increased number of dependencies and the unstable environment inherent to the Internet.

Local persistent storage will most likely give us the difference between 99.9% uptime and 95% uptime for our projects. You may say that's a small difference, but you'd only argue so if you see SL as more of a game than a metaverse.

You mean things like gesture permissions, the way clients don't switch to the new stream when you wsitch a parcel, the fact that mono streams don't cover the entire parcel, the fact that this is the 3rd version of auctions, when you set certain primitive params it kills sound effects, or that faster inventory loads are a fix to a system that was broken.



I'm not deriding your feature request, I'm merely making a statement based on historical observation.



I really don't care about that. The whole point in trying to define an open standard was so that database-dependent projects could easily be switch between different service providers, or even connected to your own data service. Personally, I'd rather not have anything on my database that I didn't design myself, because it's a real PITA to administer/work with somebody else's badly designed database schema.



I'm aware of this. I'm one of them. I've been asking for this since long before you even joined SL. I quit logging in for several months because I got so frustrated with certain LSL problems, among them the lack of persistent data storage and memory leaks/ stack-heap collisions killing any chance of writing an in-world data storage mechanism.

I came back after RPC specifically with the hope that it would be the solution to the data persistence problem. I would much rather have one system that was robust, reliable, and stable than have three systems that work most of the time.



I don't disagree with this statement. But my point is that what we really need is stuff that works, and works properly. In case you haven't bothered to notice, every minor release of SL breaks something in LSL, sometimes in the name of offering a better solution, but typically for no apparent reason at all.



Which is why I want to see it fixed before we add Yet Another Broken Feature(tm)

OK, I just read through again and realized there are two places where a make a comment about the "whole point" to an open standard, but they're two different points.

So, there are a few key points to the open standard, and neither of those mentioned are the "whole point." They are, however, significant points.

I agree with Grim. Persistent storage would be great -- if it worked. I don't believe that the Lindens' time would be best spent adding another feature though. At this point, I think actually making some of the ones we have function correctly would be much more practical. Permissions, UI bugs, rendering bugs, streaming bugs... it's HARD to write a piece of software as large as SL with so few people.

Finishing XML-RPC would eliminate much of the need for a native storage system. It'd be approximately the same speed as the horrible, horrible dataserver, and would solve far more problems.

If the Lindens ever finish it, I fully intend to release a persistent storage LSL library, and to possibly rent accounts on a server. Undoubtedly, plenty of other people would do the same. The point is that whether the Lindens have to do a lot of work, or a little, we would have an effective, accessible persistent storage solution. At this point, fixing XML-RPC is a better use of a very finite amount of development time.

I missed the point!?

</joking>

Seriously, I think it's great you are making a standard, and that's great!

But it's high time LL stepped up and provided what even simple web page accounts get, database access.