[Pharo-users] Pharo and SQLite

Jimmie Houchin jlhouchin at gmail.com
Thu Oct 15 14:31:27 EDT 2015


I would love to have an independent full featured, sold out to SQLite, 
adapter for Pharo. However, I have not written one.

The one I have installed but yet to try is the one that is included in 
Garage.
http://smalltalkhub.com/#!/~DBXTalk/Garage

But while looking at the link above, I see that it is based upon 
PharoExtras / NBSQLite3.
http://www.smalltalkhub.com/#!/~PharoExtras/NBSQLite3

I will have to check on that one and see about going to the source. I 
was considering if necessary doing my own FFI later. Might not be required.

I am not looking for any kind of generic database api to save me from 
SQL. I am not looking for being able to switch from SQLite to PostgreSQL.

I want one that is sold out to being the best way to use SQLite. I don't 
want an ORM to save me from SQL. I want sold out opinionated software. :)

So when I get back to the project, probably next week. I will definitely 
look at the NBSQLite3.

Hopefully one of these two will meet your goals, which may be different 
than mine.


Jimmie


On 10/15/2015 01:05 PM, Robert Withers wrote:
> 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