LÖVE

I'm sure the devs will be more than willing to help anyone who wants to include SQLite in their build of Love.

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?

Assume I know nothing of make files and what not.

I'm not so sure that I should throw my 2 cents in here or not...

This conversation is relevant because I was actually looking for something along the lines of SQL for LOVE. While I agree with the OP in being useful in some scenarios, I disagree about the inclusion of it in LOVE. SQL is really meant for server environments or environments that require persistent storage and quick lookups. If a client is doing some sort of logging, indexing of found articles/objects in the game over its lifetime, or any other large data-set that requires quick indexing and hashed tables then that's fine. I don't really think it is suitable for a game client.

While the features it brings I consider to be worthwhile for me in my specific project (And kinda need) it doesn't really fit the needs of the majority of users. Basically if you need something like SQL to manage your entities locations and other details, I feel you are not managing your memory right. Not to mention one key thing in regards to SQL is that it is not going to halt your code until a result is returned... The user that mentioned SQL in Garry's Mod should already know this. Callbacks will need to be written once the data is transferred and ready to be read.

As an aside... Just because the client is in LOVE does not mean the server must be. You can write a server in some other language and have it talk to Love via your favorite networking protocol. (UDP/TCPIP) 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. Problem solved.

TL/DR: While I think SQL is beneficial, it doesn't help the majority of its users. What I propose is support for it (in other words, simple modules as previously stated were already possible), but not there by default.

SQL is really meant for server environments or environments that require persistent storage and quick lookups.

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.

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.

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.

Not to mention one key thing in regards to SQL is that it is not going to halt your code until a result is returned...

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

What I propose is support for it (in other words, simple modules as previously stated were already possible), but not there by default.

A module is workable but I think the problem is that cross platform deployment becomes more difficult / less convenient.

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.

It would be nice if C Lua modules were a bit simpler to use with LÖVE.

The wiki is freely editable if you have a forum account. An entry for SQLite would fit in the Libraries section, I think.

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.

Then I misunderstood his intentions. Apologies. I may have mixed up OP's intentions with other posters.

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

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.

A module is workable but I think the problem is that cross platform deployment becomes more difficult / less convenient.

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.

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.

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.

I don't think the issue is that people don't want SQL, but rather having it be included in LOVE seems to be the main disapproval.

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.

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.

While databases are pretty cool, I indeed haven't seen many projects that would benefit from one. Certainly not a large enough number that it'd be interesting to make it a default part of love.

But, knowing myself, I'm probably going to try building a game with a database in it just because, so it's still nice to include some instructions for people who want to add it for themselves

I would also love to have a proper database for my rpg. Sure i can save all the data to XML or JSON files, but by the time the game is done there will be thousands if not 10's of thousands of things that need saved and kept track of, but it would make more sense for the data to be stored in a sqlite table. I know I'm in the minorty and most games made with love really don't need sqlite but having the option would be nice.