Pharo and SQLite

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Pharo and SQLite

Jimmie Houchin-5
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





Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Robert Withers
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
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Esteban A. Maringolo
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 <[hidden email]>:

> 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
>>
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Jimmie Houchin-5
In reply to this post by Robert Withers
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
>>
>>
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Esteban A. Maringolo
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 <[hidden email]>:

> 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
>>>
>>>
>>>
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Jimmie Houchin-5
In reply to this post by Esteban A. Maringolo
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.

Thanks.

Jimmie

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 <[hidden email]>:
>> 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
>>>
>>>
>>>
>>>
>>>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Robert Withers
In reply to this post by Esteban A. Maringolo
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
>
> Regards!
>
>
>
> Esteban A. Maringolo
>
>
> 2015-10-15 15:05 GMT-03:00 Robert Withers <[hidden email]>:
>> 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
>>>
>>>
>>>
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Mariano Martinez Peck
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 <[hidden email]> 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

Regards!



Esteban A. Maringolo


2015-10-15 15:05 GMT-03:00 Robert Withers <[hidden email]>:
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











--
Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Offray
In reply to this post by Jimmie Houchin-5
Hi Jimmie,

Nice to see you exploring bridges between Pharo and the external world
(that was my message about how I planned to contribute to pharo) and
thanks for the reference about the "Git: just say no" video from Hipp
(food for my rants with git possessed friends ;-) ).

[1] https://www.youtube.com/watch?v=ghtpJnrdgbo

My app uses fossil for storage and exports documents in plain text using
STON[2] format and with this combination I can have a remote storage
facility which is also pretty portable (just depending on Pharo and a
fossil portable binaries). Because I'm working with documents, STON
files can have long text inside, which is treated by fossil like
binaries and I had not have the time to explore some Sven's suggestions
to make it diff friendly. Also I would like some yaml import export on
Pharo (maybe via STON). Pharo + Yaml/STON + Fossil could bring us some
kind of free schema, human readable, external and distributed storage
system that can talk pretty well with the rest of the world.

Anyway I just want to point that are more people interested in simple
and external persistence using Hipps ideas and products. Maybe fossil +
STON can work for you also.

[2] https://github.com/svenvc/ston/blob/master/ston-paper.md

Keep us posted,

Offray

On 15/10/15 12:58, 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
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Jimmie Houchin-5
In reply to this post by Mariano Martinez Peck
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 <[hidden email]> 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

Regards!



Esteban A. Maringolo


2015-10-15 15:05 GMT-03:00 Robert Withers <[hidden email]>:
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











--

Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Jimmie Houchin-5
In reply to this post by Offray
Hello Offray,

If we didn't have the big push for GitHub. I would love to see a Fossil
source code interface for Pharo. If we had this we could potentially
replace SmalltalkHub with something more functional almost instantly.
This is a big assumption, but possibly correct. But since it comes with
a web ui it has a start. I just don't know what would be involved in
making it suitable for a community of projects. I just find SmalltalkHub
painful. I haven't actually started using Fossil yet. Just watched the
videos and began reading the book and drinking the kool-aid. :)

I do love how pro-active he is being in suggesting big things to
established products or ideas.

While I am very pro doing as much stuff in Pharo as possible. ie: not
using every tool out there from other languages, Python, Ruby, etc.

I do think it is a good thing when it comes to things like data
persistence to be ready to use solutions that help people feel
comfortable that they could have an exit strategy should Pharo some how
crash, go crazy, quit working or simply fade away like many believe
Smalltalk already has. It could make some people a little more
comfortable in a Pharo solution.

He talks about LibreOffice and what benefits it could have if it used
SQLite rather than a pile of files for persistency. What if Pharo was
the app and SQLite the persistency for the document? We could do our own
office suite or whatever. We would have a portable, future proof,
application file format that people beyond the Pharo/Smalltalk community
could feel good about.

Which app of yours are you referring to?

Thanks for your input.

Jimmie


On 10/15/2015 03:49 PM, Offray Vladimir Luna Cárdenas wrote:

> Hi Jimmie,
>
> Nice to see you exploring bridges between Pharo and the external world
> (that was my message about how I planned to contribute to pharo) and
> thanks for the reference about the "Git: just say no" video from Hipp
> (food for my rants with git possessed friends ;-) ).
>
> [1] https://www.youtube.com/watch?v=ghtpJnrdgbo
>
> My app uses fossil for storage and exports documents in plain text
> using STON[2] format and with this combination I can have a remote
> storage facility which is also pretty portable (just depending on
> Pharo and a fossil portable binaries). Because I'm working with
> documents, STON files can have long text inside, which is treated by
> fossil like binaries and I had not have the time to explore some
> Sven's suggestions to make it diff friendly. Also I would like some
> yaml import export on Pharo (maybe via STON). Pharo + Yaml/STON +
> Fossil could bring us some kind of free schema, human readable,
> external and distributed storage system that can talk pretty well with
> the rest of the world.
>
> Anyway I just want to point that are more people interested in simple
> and external persistence using Hipps ideas and products. Maybe fossil
> + STON can work for you also.
>
> [2] https://github.com/svenvc/ston/blob/master/ston-paper.md
>
> Keep us posted,
>
> Offray
>
> On 15/10/15 12:58, 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
>>
>>
>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Offray
Hi Jimmie,

My idea is to connect Pharo with the external world, starting from what
I need/know, but also I try to not use every single stuff in other
languages. My main criteria for selecting from other ecosystems is
simplicity. I want to make Pharo compatible with my own history (which
is kind of similar to the ones of many non-pharoers), so that bridge can
be crossed by others.

This is the app I'm refering to:

http://smalltalkhub.com/#!/~Offray/Grafoscopio

Is the one I'm making to finally learn Smalltalk with limited time, so
lots of rookie code everywhere, but works (mostly for me now). Hopefully
I will have more time to learn and improve it. I have some text I have
done using it, with open innovation and open/citizen science as themes  
(only in Spanish) and recently I made a proposal on how to use/extend it
(I have been publicizing it in another thread but details are on [1])

[1]
https://www.newschallenge.org/challenge/data/entries/data-kitchen-frictionless-data-moldable-tools-pocket-infrastructures-permanent-workshops-for-community-empowerment

Cheers,

Offray

On 15/10/15 17:10, Jimmie Houchin wrote:

> Hello Offray,
>
> If we didn't have the big push for GitHub. I would love to see a
> Fossil source code interface for Pharo. If we had this we could
> potentially replace SmalltalkHub with something more functional almost
> instantly. This is a big assumption, but possibly correct. But since
> it comes with a web ui it has a start. I just don't know what would be
> involved in making it suitable for a community of projects. I just
> find SmalltalkHub painful. I haven't actually started using Fossil
> yet. Just watched the videos and began reading the book and drinking
> the kool-aid. :)
>
> I do love how pro-active he is being in suggesting big things to
> established products or ideas.
>
> While I am very pro doing as much stuff in Pharo as possible. ie: not
> using every tool out there from other languages, Python, Ruby, etc.
>
> I do think it is a good thing when it comes to things like data
> persistence to be ready to use solutions that help people feel
> comfortable that they could have an exit strategy should Pharo some
> how crash, go crazy, quit working or simply fade away like many
> believe Smalltalk already has. It could make some people a little more
> comfortable in a Pharo solution.
>
> He talks about LibreOffice and what benefits it could have if it used
> SQLite rather than a pile of files for persistency. What if Pharo was
> the app and SQLite the persistency for the document? We could do our
> own office suite or whatever. We would have a portable, future proof,
> application file format that people beyond the Pharo/Smalltalk
> community could feel good about.
>
> Which app of yours are you referring to?
>
> Thanks for your input.
>
> Jimmie
>
>
> On 10/15/2015 03:49 PM, Offray Vladimir Luna Cárdenas wrote:
>> Hi Jimmie,
>>
>> Nice to see you exploring bridges between Pharo and the external
>> world (that was my message about how I planned to contribute to
>> pharo) and thanks for the reference about the "Git: just say no"
>> video from Hipp (food for my rants with git possessed friends ;-) ).
>>
>> [1] https://www.youtube.com/watch?v=ghtpJnrdgbo
>>
>> My app uses fossil for storage and exports documents in plain text
>> using STON[2] format and with this combination I can have a remote
>> storage facility which is also pretty portable (just depending on
>> Pharo and a fossil portable binaries). Because I'm working with
>> documents, STON files can have long text inside, which is treated by
>> fossil like binaries and I had not have the time to explore some
>> Sven's suggestions to make it diff friendly. Also I would like some
>> yaml import export on Pharo (maybe via STON). Pharo + Yaml/STON +
>> Fossil could bring us some kind of free schema, human readable,
>> external and distributed storage system that can talk pretty well
>> with the rest of the world.
>>
>> Anyway I just want to point that are more people interested in simple
>> and external persistence using Hipps ideas and products. Maybe fossil
>> + STON can work for you also.
>>
>> [2] https://github.com/svenvc/ston/blob/master/ston-paper.md
>>
>> Keep us posted,
>>
>> Offray
>>
>> On 15/10/15 12:58, 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Jimmie Houchin-5
Okay, I didn't know if you were referring to Grafoscopio or not. I did
not know it would be using Fossil for storage.

I downloaded and will explore next week.

Thanks.

Jimmie


On 10/15/2015 05:37 PM, Offray Vladimir Luna Cárdenas wrote:

> Hi Jimmie,
>
> My idea is to connect Pharo with the external world, starting from
> what I need/know, but also I try to not use every single stuff in
> other languages. My main criteria for selecting from other ecosystems
> is simplicity. I want to make Pharo compatible with my own history
> (which is kind of similar to the ones of many non-pharoers), so that
> bridge can be crossed by others.
>
> This is the app I'm refering to:
>
> http://smalltalkhub.com/#!/~Offray/Grafoscopio
>
> Is the one I'm making to finally learn Smalltalk with limited time, so
> lots of rookie code everywhere, but works (mostly for me now).
> Hopefully I will have more time to learn and improve it. I have some
> text I have done using it, with open innovation and open/citizen
> science as themes  (only in Spanish) and recently I made a proposal on
> how to use/extend it (I have been publicizing it in another thread but
> details are on [1])
>
> [1]
> https://www.newschallenge.org/challenge/data/entries/data-kitchen-frictionless-data-moldable-tools-pocket-infrastructures-permanent-workshops-for-community-empowerment
>
> Cheers,
>
> Offray
>
> On 15/10/15 17:10, Jimmie Houchin wrote:
>> Hello Offray,
>>
>> If we didn't have the big push for GitHub. I would love to see a
>> Fossil source code interface for Pharo. If we had this we could
>> potentially replace SmalltalkHub with something more functional
>> almost instantly. This is a big assumption, but possibly correct. But
>> since it comes with a web ui it has a start. I just don't know what
>> would be involved in making it suitable for a community of projects.
>> I just find SmalltalkHub painful. I haven't actually started using
>> Fossil yet. Just watched the videos and began reading the book and
>> drinking the kool-aid. :)
>>
>> I do love how pro-active he is being in suggesting big things to
>> established products or ideas.
>>
>> While I am very pro doing as much stuff in Pharo as possible. ie: not
>> using every tool out there from other languages, Python, Ruby, etc.
>>
>> I do think it is a good thing when it comes to things like data
>> persistence to be ready to use solutions that help people feel
>> comfortable that they could have an exit strategy should Pharo some
>> how crash, go crazy, quit working or simply fade away like many
>> believe Smalltalk already has. It could make some people a little
>> more comfortable in a Pharo solution.
>>
>> He talks about LibreOffice and what benefits it could have if it used
>> SQLite rather than a pile of files for persistency. What if Pharo was
>> the app and SQLite the persistency for the document? We could do our
>> own office suite or whatever. We would have a portable, future proof,
>> application file format that people beyond the Pharo/Smalltalk
>> community could feel good about.
>>
>> Which app of yours are you referring to?
>>
>> Thanks for your input.
>>
>> Jimmie
>>
>>
>> On 10/15/2015 03:49 PM, Offray Vladimir Luna Cárdenas wrote:
>>> Hi Jimmie,
>>>
>>> Nice to see you exploring bridges between Pharo and the external
>>> world (that was my message about how I planned to contribute to
>>> pharo) and thanks for the reference about the "Git: just say no"
>>> video from Hipp (food for my rants with git possessed friends ;-) ).
>>>
>>> [1] https://www.youtube.com/watch?v=ghtpJnrdgbo
>>>
>>> My app uses fossil for storage and exports documents in plain text
>>> using STON[2] format and with this combination I can have a remote
>>> storage facility which is also pretty portable (just depending on
>>> Pharo and a fossil portable binaries). Because I'm working with
>>> documents, STON files can have long text inside, which is treated by
>>> fossil like binaries and I had not have the time to explore some
>>> Sven's suggestions to make it diff friendly. Also I would like some
>>> yaml import export on Pharo (maybe via STON). Pharo + Yaml/STON +
>>> Fossil could bring us some kind of free schema, human readable,
>>> external and distributed storage system that can talk pretty well
>>> with the rest of the world.
>>>
>>> Anyway I just want to point that are more people interested in
>>> simple and external persistence using Hipps ideas and products.
>>> Maybe fossil + STON can work for you also.
>>>
>>> [2] https://github.com/svenvc/ston/blob/master/ston-paper.md
>>>
>>> Keep us posted,
>>>
>>> Offray
>>>
>>> On 15/10/15 12:58, 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

Offray
Thanks. Any code review or comments are welcomed. No interface now
between fossil and grafoscopio. I just put all my STON files there, but
STON + fossil is a combination you could consider also.

Cheers,

Offray

On 15/10/15 23:00, Jimmie Houchin wrote:

> Okay, I didn't know if you were referring to Grafoscopio or not. I did
> not know it would be using Fossil for storage.
>
> I downloaded and will explore next week.
>
> Thanks.
>
> Jimmie
>
>
> On 10/15/2015 05:37 PM, Offray Vladimir Luna Cárdenas wrote:
>> Hi Jimmie,
>>
>> My idea is to connect Pharo with the external world, starting from
>> what I need/know, but also I try to not use every single stuff in
>> other languages. My main criteria for selecting from other ecosystems
>> is simplicity. I want to make Pharo compatible with my own history
>> (which is kind of similar to the ones of many non-pharoers), so that
>> bridge can be crossed by others.
>>
>> This is the app I'm refering to:
>>
>> http://smalltalkhub.com/#!/~Offray/Grafoscopio
>>
>> Is the one I'm making to finally learn Smalltalk with limited time,
>> so lots of rookie code everywhere, but works (mostly for me now).
>> Hopefully I will have more time to learn and improve it. I have some
>> text I have done using it, with open innovation and open/citizen
>> science as themes  (only in Spanish) and recently I made a proposal
>> on how to use/extend it (I have been publicizing it in another thread
>> but details are on [1])
>>
>> [1]
>> https://www.newschallenge.org/challenge/data/entries/data-kitchen-frictionless-data-moldable-tools-pocket-infrastructures-permanent-workshops-for-community-empowerment
>>
>> Cheers,
>>
>> Offray
>>
>> On 15/10/15 17:10, Jimmie Houchin wrote:
>>> Hello Offray,
>>>
>>> If we didn't have the big push for GitHub. I would love to see a
>>> Fossil source code interface for Pharo. If we had this we could
>>> potentially replace SmalltalkHub with something more functional
>>> almost instantly. This is a big assumption, but possibly correct.
>>> But since it comes with a web ui it has a start. I just don't know
>>> what would be involved in making it suitable for a community of
>>> projects. I just find SmalltalkHub painful. I haven't actually
>>> started using Fossil yet. Just watched the videos and began reading
>>> the book and drinking the kool-aid. :)
>>>
>>> I do love how pro-active he is being in suggesting big things to
>>> established products or ideas.
>>>
>>> While I am very pro doing as much stuff in Pharo as possible. ie:
>>> not using every tool out there from other languages, Python, Ruby, etc.
>>>
>>> I do think it is a good thing when it comes to things like data
>>> persistence to be ready to use solutions that help people feel
>>> comfortable that they could have an exit strategy should Pharo some
>>> how crash, go crazy, quit working or simply fade away like many
>>> believe Smalltalk already has. It could make some people a little
>>> more comfortable in a Pharo solution.
>>>
>>> He talks about LibreOffice and what benefits it could have if it
>>> used SQLite rather than a pile of files for persistency. What if
>>> Pharo was the app and SQLite the persistency for the document? We
>>> could do our own office suite or whatever. We would have a portable,
>>> future proof, application file format that people beyond the
>>> Pharo/Smalltalk community could feel good about.
>>>
>>> Which app of yours are you referring to?
>>>
>>> Thanks for your input.
>>>
>>> Jimmie
>>>
>>>
>>> On 10/15/2015 03:49 PM, Offray Vladimir Luna Cárdenas wrote:
>>>> Hi Jimmie,
>>>>
>>>> Nice to see you exploring bridges between Pharo and the external
>>>> world (that was my message about how I planned to contribute to
>>>> pharo) and thanks for the reference about the "Git: just say no"
>>>> video from Hipp (food for my rants with git possessed friends ;-) ).
>>>>
>>>> [1] https://www.youtube.com/watch?v=ghtpJnrdgbo
>>>>
>>>> My app uses fossil for storage and exports documents in plain text
>>>> using STON[2] format and with this combination I can have a remote
>>>> storage facility which is also pretty portable (just depending on
>>>> Pharo and a fossil portable binaries). Because I'm working with
>>>> documents, STON files can have long text inside, which is treated
>>>> by fossil like binaries and I had not have the time to explore some
>>>> Sven's suggestions to make it diff friendly. Also I would like some
>>>> yaml import export on Pharo (maybe via STON). Pharo + Yaml/STON +
>>>> Fossil could bring us some kind of free schema, human readable,
>>>> external and distributed storage system that can talk pretty well
>>>> with the rest of the world.
>>>>
>>>> Anyway I just want to point that are more people interested in
>>>> simple and external persistence using Hipps ideas and products.
>>>> Maybe fossil + STON can work for you also.
>>>>
>>>> [2] https://github.com/svenvc/ston/blob/master/ston-paper.md
>>>>
>>>> Keep us posted,
>>>>
>>>> Offray
>>>>
>>>> On 15/10/15 12:58, 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Pharo and SQLite

HilaireFernandes
In reply to this post by Mariano Martinez Peck
Le 15/10/2015 20:54, Mariano Martinez Peck a écrit :
> 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.

Fuel is *great* indeed to persist a tree of objects.
However, one of the greatest downside compare to SQLite is the file
format is not stable from one version of Fuel to another one. Is it a
mandatory limitation?

Hilaire

--
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu