Re: [Pharo-users] Pharo and SQLite

[Hilaire]

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

Re: [Pharo-users] Pharo and SQLite

[Offray Vladimir Luna Cárdenas]

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 s

Re: [Pharo-users] Pharo and SQLite

[Jimmie Houchin]

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 whomeve

Re: [Pharo-users] Pharo and SQLite

[Offray Vladimir Luna Cárdenas]

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 s

Re: [Pharo-users] Pharo and SQLite

[Jimmie Houchin]

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 abov

Re: [Pharo-users] Pharo and SQLite

[Jimmie Houchin]

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 
mailto:robert.w.with...@gmail.com>> wrote:


Thanks to both of you for the links. I appreciate you.

Robert


On 10/15/2015 02:22 PM, Esteban A. Maringolo wrote:

I haven't used SQLite in Pharo, but I used it in Android. It is a
pretty complete database solution, self contained in a single file
(and a shared library ;-)).

I already posted the slides of the PgCon where Richard Hipp states
that SQLite is the replacement of fopen() and not of a whole
RDBMS:

http://www.pgcon.org/2014/schedule/attachments/319_PGCon2014OpeningKeynote.pdf

You already have drivers for it here:
http://www.smalltalkhub.com/#!/~PharoExtras/NBSQLite3


Regards!



Esteban A. Maringolo


2015-10-15 15:05 GMT-03:00 Robert Withers
mailto:robert.w.with...@gmail.com>>:

Hi Jimmie,

Is this SQlite adaptor you wrote published publicly? I'd
definitely like to
evaluate this technology for my stack.

Thank you,
Robet


On 10/15/2015 01:58 PM, Jimmie Houchin wrote:


Hello,

I am working on a project for my wife. I initially
thought I would keep
all my data inside Pharo because it is a simple
project and Pharo is
great at persistence in the image.

But as I pursued the project it felt like I was
reinventing the
database. So I thought why am I considering working so
hard to structure
my classes and objects in such a way that I am in
effect writing my own
database. All of this to avoid using a "real" database.

Part of my p

Re: [Pharo-users] Pharo and SQLite

[Offray Vladimir Luna Cárdenas]

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

Re: [Pharo-users] 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 
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 :
>>
>>> 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 Appl

Re: [Pharo-users] Pharo and SQLite

[Robert Withers]

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 :

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

Re: [Pharo-users] Pharo and SQLite

[Jimmie Houchin]

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 :

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 ide

Re: [Pharo-users] 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 :
> 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.

Re: [Pharo-users] Pharo and SQLite

[Jimmie Houchin]

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
cour

Re: [Pharo-users] 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 :
> 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 

Re: [Pharo-users] 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

[Pharo-users] Pharo and SQLite

[Jimmie Houchin]

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