I would be filled with joy if sqlite was included (like Gideros and CoronaSDK). However since there seems a trend of not including it (this makes me very sad), can anyone point me in the direction of how to manually include it on OSX?I'm sure the devs will be more than willing to help anyone who wants to include SQLite in their build of Love.
Mentioning 'servers' is off topic. MySQL is a multi-connection database that lives on a server but that's not what the OP is asking for. The OP would like SQLite which is queryable local storage for a single-connection (i.e. the player). SQLite is appropriate for many applications particularly for large datasets.SQL is really meant for server environments or environments that require persistent storage and quick lookups.
Correct. A MMO game needs a serverside database. In this scenario there is hardly any client persistent data so SQLite would unlikely be needed. However, this is not what the OP asked for.If the OP is looking for some sort of an MMO game, then he/she could use a server model that is written outside of LOVE that supports SQL and just send the data in a serialized form to the clients, decode it, and BAM.
There is a small delay when reading/writing to SQLite opposed to changing variables in memory but that delay isn't always a problem. Imagine a turn-based game for a space game with 10,000 planets each with 20 variables (i.e. 200000), the data can be manipulated during the player's thinking time, so the read/write time isn't ever observed. But crucially the game doesn't have to keep every variable in memory all the time. Also note the read/write time for parsing and saving large XML or JSON files would likely take longer (because it's writing to the filesystem opposed to a database) and more CPU (because it is a more intensive task). Note: If you don't think 200000 is large enough simply imagine a larger numberNot to mention one key thing in regards to SQL is that it is not going to halt your code until a result is returned...
A module is workable but I think the problem is that cross platform deployment becomes more difficult / less convenient.What I propose is support for it (in other words, simple modules as previously stated were already possible), but not there by default.
Then I misunderstood his intentions. Apologies. I may have mixed up OP's intentions with other posters.Mentioning 'servers' is off topic. MySQL is a multi-connection database that lives on a server but that's not what the OP is asking for. The OP would like SQLite which is queryable local storage for a single-connection (i.e. the player). SQLite is appropriate for many applications particularly for large datasets.
Which was exactly my point... Users cant simply turn a query into a boolean in an if statement or some other variable. They have to wait for the result to come into memory before they can apply it towards actual calculations. That was what I was attempting to express.There is a small delay when reading/writing to SQLite opposed to changing variables in memory but that delay isn't always a problem. Imagine a turn-based game for a space game with 10,000 planets each with 20 variables (i.e. 200000), the data can be manipulated during the player's thinking time, so the read/write time isn't ever observed. But crucially the game doesn't have to keep every variable in memory all the time. Also note the read/write time for parsing and saving large XML or JSON files would likely take longer (because it's writing to the filesystem opposed to a database) and more CPU (because it is a more intensive task). Note: If you don't think 200000 is large enough simply imagine a larger number
Not knowing much about the internals of SQL, only how to use it extremely well, I may come off as being idiotic here... but assuming exposed functionality of SQL is the same (eg. functions, parameters, calls, etc) wouldn't the only issue be which version of the library the client has? So if the target OS is linux, include a linux version library, Windows? Windows library? I don't believe this is really the goal of LOVE per say, but I don't really consider it to be any sort of "inconvenience" on the developer's end... much less on the end user.A module is workable but I think the problem is that cross platform deployment becomes more difficult / less convenient.
Agreed as well. Not to mention there's a higher chance of the end user tinkering and messing something up, whether it be a parser issue, or inconsistent states... But that is all kinda off-topic I guess.As mentioned by others, SQLite is very powerful and useful. XML, JSON and Lua tables all have their place but they don't replace SQLite's features. Gideros and CoronaSDK, Moai and even web browsers from 2010 (under the name WebSQL) all support SQLite. I come from relational database background so I have to disagree with the suggestion that parsing text files is an adequate substitute.
This thread has had over 2000 views in 5 weeks, so clearly there is some interest. My preference would be for it to be included like the other Lua engines. 2nd preference is for an install guide to be added to the wiki. And obviously there will be some bias here because many of you won't be using SQLite (partly because it's not mentioned in the wiki or available in API), that's not to say it's not useful.
Oh, no. This is an issue. The whole platform independence is a major selling point for LÖVE. I think the only solution for an optional sqlite module would be a pure Lua module. On the other hand, I don't think there is an actual need for any SQL in LÖVE games, just people wanting it.severedskullz wrote:I don't believe this is really the goal of LOVE per say, but I don't really consider it to be any sort of "inconvenience" on the developer's end... much less on the end user.
Users browsing this forum: Google [Bot], jradcoolness and 7 guests
