[Pharo-users] Pharo and SQLite

Jimmie Houchin jlhouchin at gmail.com
Thu Oct 15 14:42:13 EDT 2015

Thanks for the reply.

When I went to answer Robert, I saw that driver. I will definitely give 
it a try.

I don't find the post with those slides. But I have watched the video. 
It is a good video. Funny!
But I did see the one where you posted about advocacy.

But this is why I think that SQLite is a good match for Pharo. 
Delivering simple, small solutions, portably and easily deployable.



On 10/15/2015 01:22 PM, Esteban A. Maringolo wrote:
> I haven't used SQLite in Pharo, but I used it in Android. It is a
> pretty complete database solution, self contained in a single file
> (and a shared library ;-)).
> I already posted the slides of the PgCon where Richard Hipp states
> that SQLite is the replacement of fopen() and not of a whole RDBMS:
> http://www.pgcon.org/2014/schedule/attachments/319_PGCon2014OpeningKeynote.pdf
> You already have drivers for it here:
> http://www.smalltalkhub.com/#!/~PharoExtras/NBSQLite3
> Regards!
> Esteban A. Maringolo
> 2015-10-15 15:05 GMT-03:00 Robert Withers <robert.w.withers at gmail.com>:
>> Hi Jimmie,
>> Is this SQlite adaptor you wrote published publicly? I'd definitely like to
>> evaluate this technology for my stack.
>> Thank you,
>> Robet
>> On 10/15/2015 01:58 PM, Jimmie Houchin wrote:
>>> Hello,
>>> I am working on a project for my wife. I initially thought I would keep
>>> all my data inside Pharo because it is a simple project and Pharo is
>>> great at persistence in the image.
>>> But as I pursued the project it felt like I was reinventing the
>>> database. So I thought why am I considering working so hard to structure
>>> my classes and objects in such a way that I am in effect writing my own
>>> database. All of this to avoid using a "real" database.
>>> Part of my projects goals is to keep this project contained. I do not
>>> want to require my wife or whomever I share this with to have to install
>>> anything other than copy or unzip the Pharo folder. No PostgreSQL or
>>> MongoDB installs. Keep it simple.
>>> This is a goal I have for a lot of my ideas.
>>> In my 20+ years of computing and Internet. I have seen lots of
>>> applications come and go.
>>> (and no, I don't have gray hair, even though I have children older than
>>> probably half the people here.)
>>> Many years ago, my wife and I made tremendous use out of Apple Works and
>>> Microsoft Works. Apple at home and for me Microsoft at work. We loved
>>> the ease and simplicity we could throw a database together and just do
>>> stuff. It was great. In fact on my work PC I still use weekly and
>>> sometimes daily a database I wrote in 1994. I am almost at the point
>>> that Windows won't run this ancient MSWorks 4 database. I will have to
>>> move my data.
>>> Of course these tools aren't the greatest. They have significant
>>> limitations, but despite the limitations they were very empowering.
>>> My wife started to attempt something similar in LibreOffice but
>>> LibreOffice wasn't so simple. It was confusing to her. I briefly looked
>>> at LibreOffice but I am not convinced that it is the best or right tool
>>> for the job.
>>> So that sent me on an adventure to implement this in Pharo. In my
>>> learning that I don't want to reinvent the database I have initially
>>> settled on using SQLite. SQLite meets my requirements above. It is
>>> embedded in my Pharo app and only requires including the database file I
>>> create. Very portable and easy to install along with anything else in
>>> Pharo.
>>> SQLite seems like a very good match and complement to Pharo. A trusted,
>>> reliable, external persistence that is as simple and portable as is Pharo.
>>> Richard Hipp creator of SQLite has several videos describing how he
>>> believes SQLite should be used and should not be used.
>>> SQLite: The Database at the Edge of the Network with Dr. Richard Hipp
>>> https://www.youtube.com/watch?v=Jib2AmRb_rk
>>> 2014 SouthEast LinuxFest - Richard Hipp - SQLite as an Application File
>>> Format
>>> https://www.youtube.com/watch?v=8y_ABXwYtuc
>>> The videos are inspirational for using SQLite. I like what he says. I
>>> encourage watching. I have watched these and others of his including his
>>> anti-git video.
>>> I am not knowledgeable about the use of git in Pharo, but I would be
>>> interested if anybody has considered and knows the pros and cons of
>>> using Fossil instead. I know, it wouldn't get us on GitHub. I may be the
>>> only one. But that isn't a biggie for me.
>>> TL;DW (didn't watch)
>>> Use SQLite for Application File Format for persistence instead of a
>>> (zipped) pile of files and you get many benefits. Examples in videos as
>>> the wrong way, LibreOffice and git.
>>> I think using SQLite like this for Pharo would be an excellent match. We
>>> gain all the benefits of SQLite, transactions, ACID. In a tool that is
>>> nicely (non)licensed, and is used and trusted generally by most all of
>>> the software world.
>>> For Pharo this buys us an excellent, simple, equally portable
>>> persistence. It also buys us persistence that is trusted by people who
>>> don't trust the image for their data. This could possible help with
>>> people who explore Pharo but aren't comfortable about image only. Now of
>>> course it won't help the Emacs or Vim, ... people.
>>> I am exploring the idea of using Pharo and SQLite for what I would have
>>> previously used Apple/MS Works database for. At first it would be
>>> building the app/project for my wife. And during and after that project
>>> generalize some things to make a better out of the box solution for like
>>> projects.
>>> Thoughts, opinions, ideas, wisdom. Any and all appreciated.
>>> Thanks.
>>> Jimmie

More information about the Pharo-users mailing list