On Wed, Sep 24, 2014 at 01:33:02PM -0300, Esteban A. Maringolo wrote:

How does SQLite scale in terms of table size and so on?

According to https://www.sqlite.org/whentouse.html: An SQLite database is limited in size to 140 terabytes (2^47 bytes, 128 tibibytes). And even if it could handle larger databases, SQLite stores the entire database in a single disk file and many filesystems limit the maximum size of files to something less than this. SQLite will normally work fine as the database backend to a website. But if you website is so busy that you are thinking of splitting the database component off onto a separate machine, then you should definitely consider using an enterprise-class client/server database engine instead of SQLite.

I was surprised to know it is based on an old version of PostgreSQL according to this presentation: http://www.pgcon.org/2014/schedule/events/736.en.html

That is a very interesting talk. As it says, SQLite is a replacement for fopen(), not a replacement for PostgreSQL. In the context of my writing tools and applications in Smalltalk, I'd like to enjoy SQLite's robustness, hence my interest in having/building a good Smalltalk wrapper. Pierce

On Fri, Oct 03, 2014 at 09:19:15PM -0700, Sanjay-M wrote:

I was wondering if this approach could be adopted in developing a Client/Server application with a separate server component accessing the SQLite database (on a separate machine).

Using HTTP/S as the client-server protocol, have the web app server manage data persistence, be it SQLite, GOODS or Gemstone, ...? Pierce

Sanjay-M <sm@planage.com> wrote:

I was wondering if this approach could be adopted in developing a Client/Server application with a separate server component accessing the SQLite database (on a separate machine).

If a template / model can be developed i am sure this can be very useful in creating larger multi-user applications even at the cost of some duplication / redundant effort.

I am thinking of situations where we cannot have a web server even on the intranet - more like traditional servers accessed over TCP/IP

Sorry but I can't follow your question. SQLite is a file based RDBMS engine, designed to be accessed locally and not through TCP/IP. If what you need to do is run over a network PostgreSQL will provide you with such feature (plus a lot others). Remember: “SQLite is not a replacement for PostgreSQL [or any other RDBMS]. SQLite is a replacement for fopen().” Regards. Esteban A. Maringolo

2014-10-06 14:11 GMT-03:00 Sanjay-M <sm@planage.com>:

what I was saying was supposing we write a server that alone only accesses the SQLite database. Users behave like clients accessing the server over TCP/IP. and the text i pointed to in my earlier mail detailed how such a scenario could be implemented. If someone could write a small sample with say one class then it could be easier to understand / implement

But that has nothing to do with SQLite nor any other persistence solution. In fact most web applications work that way, where the messaging runs over HTTP (and hence TCP/IP) and the server responds to them. NBSQLite3 is a good solution for self contained applications, where you can distribute everything without requiring the installation/configuration of any third party DB server. If you can't have a web server in your network environment (i.e. intranet/LAN) how will you have any other TCP/IP based server? I mean, if you want to run a Pharo image as your server tier, unless you have certain port/policies restrictions, it will make no difference whether you run an HTTP server or your [put your custom protocol here] server. Regards!

Pierce, Thank you for the answers. Is the wrapper thread safe? I understan the library is thread-safe per se (at least in Android+Java it is), so using the wrapper in Pharo (single-threaded at the OS level) wouldn't cause issues. But I don't know how NativeBoost plays here. Regards! Esteban A. Maringolo 2014-09-25 13:40 GMT-03:00 Pierce Ng <pierce@samadhiweb.com>:

On Wed, Sep 24, 2014 at 01:33:02PM -0300, Esteban A. Maringolo wrote:

...

How does SQLite scale in terms of table size and so on?

According to https://www.sqlite.org/whentouse.html:

An SQLite database is limited in size to 140 terabytes (2^47 bytes, 128 tibibytes). And even if it could handle larger databases, SQLite stores the entire database in a single disk file and many filesystems limit the maximum size of files to something less than this.

SQLite will normally work fine as the database backend to a website. But if you website is so busy that you are thinking of splitting the database component off onto a separate machine, then you should definitely consider using an enterprise-class client/server database engine instead of SQLite.

...

I was surprised to know it is based on an old version of PostgreSQL according to this presentation: http://www.pgcon.org/2014/schedule/events/736.en.html

That is a very interesting talk. As it says, SQLite is a replacement for fopen(), not a replacement for PostgreSQL. In the context of my writing tools and applications in Smalltalk, I'd like to enjoy SQLite's robustness, hence my interest in having/building a good Smalltalk wrapper.

Pierce

On Fri, Oct 03, 2014 at 10:44:43PM +0200, stepharo wrote:

Cool what is NBSQLite3 (a nativeboost version)? Nice. Would be nice once you API stabilize that we get a chapter or on NBSQLite3 :)

Yes, NativeBoost interface to SQLite. Yes, I plan to write a chapter on it. :-) Pierce