https://www.postgresql.org/docs/current/datatype.html
I am leaning "Array types" but figure I should ask first.
cordially
I've recently been digging into the same thing and spotted
- hstore, specifically for key/value pairs, you have to enable the extension - array, which seems to be mostly for arrays of the same kind of data, so you'd have to define a custom type for the pairs you are interested in - json, which is just json string. Given we have pretty good json handling, this seems like a very simple one to use
On 2023-09-06, at 5:54 AM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
https://www.postgresql.org/docs/current/datatype.html
I am leaning "Array types" but figure I should ask first.
cordially
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- RIGOR MORRIS - The cat is dead
I recommend you use jsonb.
I would consider arrays and hstore to be legacy data types these days.
On Sep 6, 2023, at 5:54 AM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
https://www.postgresql.org/docs/current/datatype.html https://www.postgresql.org/docs/current/datatype.html
I am leaning "Array types" but figure I should ask first.
cordially
That is convincing and I need to familiarize myself with squeak json .toocordially ---- On Wed, 06 Sep 2023 13:34:51 -0400 squeak-dev@lists.squeakfoundation.org wrote ----I recommend you use jsonb.I would consider arrays and hstore to be legacy data types these days.On Sep 6, 2023, at 5:54 AM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:https://www.postgresql.org/docs/current/datatype.htmlI am leaning "Array types" but figure I should ask first.cordially
On 2023-09-06, at 1:11 PM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
That is convincing and I need to familiarize myself with squeak json .too
It's reasonably simple; take a look at JsonTests, implementors of #jsonWriteOn: etc. I'd skip the json methods in WebUtils, not because it is bad but because we're aiming to unify the two and it's best to not get confused.
A very useful capability is specifying special purpose encoder/decoders that allow you to have special formats for your own classes - for example before I started working to write my weatherstation data to postgresql I had a custom json method for the data points.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A conclusion is the place where you got tired of thinking.
I will be putting this in Doc Help via emacs org notes. thx ---- On Wed, 06 Sep 2023 16:31:26 -0400 tim@rowledge.org wrote ----
On 2023-09-06, at 1:11 PM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
That is convincing and I need to familiarize myself with squeak json .too
It's reasonably simple; take a look at JsonTests, implementors of #jsonWriteOn: etc. I'd skip the json methods in WebUtils, not because it is bad but because we're aiming to unify the two and it's best to not get confused.
A very useful capability is specifying special purpose encoder/decoders that allow you to have special formats for your own classes - for example before I started working to write my weatherstation data to postgresql I had a custom json method for the data points.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A conclusion is the place where you got tired of thinking.
A swiki page would be much more likely to get found and read by squeakers...
On 2023-09-06, at 3:28 PM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
I will be putting this in Doc Help via emacs org notes.
thx
---- On Wed, 06 Sep 2023 16:31:26 -0400 tim@rowledge.org wrote ----
On 2023-09-06, at 1:11 PM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
That is convincing and I need to familiarize myself with squeak json .too
It's reasonably simple; take a look at JsonTests, implementors of #jsonWriteOn: etc. I'd skip the json methods in WebUtils, not because it is bad but because we're aiming to unify the two and it's best to not get confused.
A very useful capability is specifying special purpose encoder/decoders that allow you to have special formats for your own classes - for example before I started working to write my weatherstation data to postgresql I had a custom json method for the data points.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A conclusion is the place where you got tired of thinking.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The substance "Hey Y'all, watch this!" is known by the state of California to be hazardous to your health.
I will see if I can modify Doc to post to the swiki too. I will add a note to the tool.
Doc is working, it gives me a way to take the distributed information and bring it into squeak as a Help Topics quickly.
I profoundly dislike having to spend hours reverse engineering to understand basic usage of things.
It took me a month to learn that the javascript classes in Seaside are not the things to use to work with javascript in Seaside.
Its not that the classes are very limited in what they do, but the wasted time spent figuring out I was on the wrong track.
Furthermore, other languages have different models of information dispersal and they work very well.
Stack Overflow is very valuable, the Postgres help pages are outstanding, it is Squeak that has the very limited information infrastructure.
Furthermore, keystrokes.
In Emacs, I can do amazing things with text editing that are not possible in any GUI I have ever worked with, especially squeak.
Why reinvent the wheel?
One could ask, "Why not implement a statistics platform in Squeak?" but then one would answer, "R".
The best tools for the job is my philosophy and for text editing and accessing help, Squeak is not the answer.
Also, I freaking hate wikis.
cordially
---- On Wed, 06 Sep 2023 22:29:33 -0400 Tim Rowledge tim@rowledge.org wrote ---
A swiki page would be much more likely to get found and read by squeakers...
On 2023-09-06, at 3:28 PM, gettimothy via Squeak-dev mailto:squeak-dev@lists.squeakfoundation.org wrote:
I will be putting this in Doc Help via emacs org notes.
thx
---- On Wed, 06 Sep 2023 16:31:26 -0400 mailto:tim@rowledge.org wrote ----
On 2023-09-06, at 1:11 PM, gettimothy via Squeak-dev mailto:squeak-dev@lists.squeakfoundation.org wrote:
That is convincing and I need to familiarize myself with squeak json .too
It's reasonably simple; take a look at JsonTests, implementors of #jsonWriteOn: etc. I'd skip the json methods in WebUtils, not because it is bad but because we're aiming to unify the two and it's best to not get confused.
A very useful capability is specifying special purpose encoder/decoders that allow you to have special formats for your own classes - for example before I started working to write my weatherstation data to postgresql I had a custom json method for the data points.
tim
tim Rowledge; mailto:tim@rowledge.org; http://www.rowledge.org/tim A conclusion is the place where you got tired of thinking.
tim
Perfect, thank you.
( (Json newWithConstructors: {JsonDummyTestObject.}) readFrom: '{"bar": "baz", "balance": 7.77, "active":false}' readStream) asDictionary
Now to figure out the reverse.
good fun.
thx
---- On Wed, 06 Sep 2023 13:34:51 -0400 Todd Blanchard via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote ---
I recommend you use jsonb.
I would consider arrays and hstore to be legacy data types these days.
On Sep 6, 2023, at 5:54 AM, gettimothy via Squeak-dev mailto:squeak-dev@lists.squeakfoundation.org wrote:
https://www.postgresql.org/docs/current/datatype.html
I am leaning "Array types" but figure I should ask first.
cordially
Interesting, PG3 takes the postgres jsonb type and converts it into a JsonObject for me.
So, instead of doing asDictionary, I suspect that I should I be able to work on the JsonObject directly without converting it.
heh...there was a moment of "oh! this changes everything" when I saw the
Object asPG3SqlLiteral
Where I thought I could store objects in the database Postgres database directly, but the attempt on an instance of the object only created the Object name
Since my objects are only data-buckets...I wonder if it is worth pursuing.
Has anybody done this?
I tried an experiment where I stored millions of objects in-image, which was fine except I needed 70Gb of RAM to store the image in-memory, and IIRC I only had about 35Gb of RAM.
If I could get that same sort of functionality by storing objects in Postgres, that would be awesome and a lot of fun to explore.
cordially
---- On Thu, 07 Sep 2023 08:22:53 -0400 gettimothy gettimothy@zoho.com wrote ---
Perfect, thank you.
( (Json newWithConstructors: {JsonDummyTestObject.}) readFrom: '{"bar": "baz", "balance": 7.77, "active":false}' readStream) asDictionary
Now to figure out the reverse.
good fun.
thx
---- On Wed, 06 Sep 2023 13:34:51 -0400 Todd Blanchard via Squeak-dev mailto:squeak-dev@lists.squeakfoundation.org wrote ---
I recommend you use jsonb.
I would consider arrays and hstore to be legacy data types these days.
On Sep 6, 2023, at 5:54 AM, gettimothy via Squeak-dev mailto:squeak-dev@lists.squeakfoundation.org wrote:
https://www.postgresql.org/docs/current/datatype.html
I am leaning "Array types" but figure I should ask first.
cordially
On 2023-09-07, at 6:02 AM, gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
Interesting, PG3 takes the postgres jsonb type and converts it into a JsonObject for me.
So, instead of doing asDictionary, I suspect that I should I be able to work on the JsonObject directly without converting it.
Yes, it is a Json object and you can thus do things like accessing items within it by their name - since it cleverly traps the mNU and works it out for you.
heh...there was a moment of "oh! this changes everything" when I saw the
Object asPG3SqlLiteral
Where I thought I could store objects in the database Postgres database directly, but the attempt on an instance of the object only created the Object name
Relational databases are really good at storing huge lists of identical structure rows. Arbitrary structures such as we most commonly use in Smalltalk are not a good match and that's why you need sometimes very complicated code to map from one to the other. It's why GemStone was invented, and Magma, and Glorp - all worth looking up.
If your data includes large lists of the same format, directly using postgresql etc should be fine. My weatherstation stuff for example has a gazillion simple rows of sensor id, the date/time of the reading, the type (temp, humidity, rainfall, etc) and the actual value. Perfect for a relational db table.
If you have more complex structures it might be smart to look at json databases like mongodb as well. (As an aside, I'm a bit confused about mongodb and whether it is open source, free or commercial, etc. Every time I look at a page that appears to offer a 'free download' it seems to try to push me towards a paid option) So far as I can see there is a very old squeak to mongodb interface on squeaksource (http://www.squeaksource.com/MongoTalk.html, an apparently newer version at http://www.smalltalkhub.com/MongoTalkTeam/mongotalk/ ) and a broader spectrum db access package at http://www.squeaksource.com/SqueakDBX
And all that is why I spent much of my life avoiding having anything to do with the damned things.
In Emacs, I can do amazing things with text editing that are not possible in any GUI I have ever worked with, especially squeak. Why reinvent the wheel?
Emacs isn't a wheel, it's a forest of bizarre complicated round-things that can, under some circumstances, be used for wheel-like purposes but only if you remember a gazillion insane key combinations that seem to reularly require more fingers than any natural human has ever had (and I include the small number of people with hexadactily). I used emacs for several years, decades ago, and I still get shudders when it is mentioned.
Also, I freaking hate wikis.
Now that's just plain wrong ;-)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Meets quality standards: It compiles without errors.
squeak-dev@lists.squeakfoundation.org