Garage's SQLite driver is a clone, albeit outdated, of the NBSQLite3 codebase.
So you better stick with NBSQlite3. Esteban A. Maringolo 2015-10-15 15:31 GMT-03:00 Jimmie Houchin <jlhouc...@gmail.com>: > 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 >>> >>> >>> >>> >>> >> > >
