Thanks for the reply.
My idea at the moment to write the application as the user interface to
the SQLite database. I do want all of the rdb features. I also
explicitly want something that is usable from other languages or
environments. I might someday think LuaJIT to be the direction I want to
go or whatever. So I want my data to be usable by most anybody. And I
think this view is a good thing for Pharo. I want Pharo to win because
it is the best solution. Not because of any particular technology lock-in.
As I was thinking about the searches that my wife will want in this
recipe database. It seemed to me that there was no easy searches just
iterating through collections of objects. Which is why in my initial
naive thinking that as I approached the problem it felt that in order to
search like we wanted to search it was not a simple solution regardless
of keeping it all Pharo and persisting in the image or moving the data
to an SQLite database. It just felt like I was going to write database
like methods to search over my collections and join and filter data from
hither, thither and yon. It seemed like moving to a real database would
be a win. I could be wrong and have a misconception of how to properly
solve the problem in Pharo/Smalltalk. I am completely open to my naive
initial conception being wrong. I am far from expert.
As I worked on the project and discussed it with my customer. This is my
first project with a customer. The project kept growing in scope and
requirements.
While I do have a customer, I do have an excellent relationship with my
customer. So I do have the liberty to learn and grow and even change
directions in this project using the technology of my choosing. :)
At the moment I am choosing Pharo and SQLite.
I at present do not see that writing an app on top of an SQLite database
would be more difficult than doing so in something like Lua. Unless
being less OO and more function is a big win.
I also somewhat have the thought of doing a test fork of the project in
a pure Pharo version. This just to test my present assumptions.
Whatever I do will be released with the exception of the recipes. The
content is not mine. :)
Who knows, my wife might be willing to release also. :)
That would test the scaling feature of the project. Most of you all
don't need recipes in our quantity.
Thanks.
Jimmie
On 10/15/2015 01:54 PM, Mariano Martinez Peck wrote:
Hi Jimmie,
Your approach seems very good from my point of view. As you know,
making directly SQL queries or even writing mappings via a relational
mapper are always a pain. So, my comment is that if you are willing to
NOT have acid, transactions, and many other of the relational db
features, you can use a simple one-file based approach like using
plain Fuel, or even SandstoneDB with Fuel. This scales well for
small/medium apps. The good thing with this approaches is that you do
not need to map classes to tables, and avoid having write queries
etc. Pros and cons, as always.
Cheers,
On Thu, Oct 15, 2015 at 3:43 PM, Robert Withers
<robert.w.with...@gmail.com <mailto:robert.w.with...@gmail.com>> wrote:
Thanks to both of you for the links. I appreciate you.
Robert
On 10/15/2015 02: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
<http://www.smalltalkhub.com/#%21/%7EPharoExtras/NBSQLite3>
Regards!
Esteban A. Maringolo
2015-10-15 15:05 GMT-03:00 Robert Withers
<robert.w.with...@gmail.com <mailto:robert.w.with...@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
--
Mariano
http://marianopeck.wordpress.com
