Which PostgreSQL client?
Locked
 
|
Hola!
Just curious- what PostgreSQL client do you folks here on the list recommend? There seem to be two implementations: http://www.io.com/~jimm/projects/squeak_postgresql/ and http://ca.geocities.com/zazu@.../pgsqueak/ (though a newer version is on SM here: http://map.squeak.org/package/ a8d3ca99-f5f4-45e0-9aa7-100a77b64f45/autoversion/3) Any thoughts on which might be better? I'm going to use it for writing reports, drawing from info we have in a PG db. I had to write a couple in Python, but I've gotten the go ahead to do my new ones in Squeak. I've been using the pg module for Python, and for writing reports I appreciate the simplicity, compared to the full-blown PyGreSQL package. I'm not using this for a web app or anything too hardcore- my co-worker or I run them periodically. I mention how I'll be using it because the usual considerations for a decision like this- speed, SSL support, etc- take a back-seat to how easy to use the API is. Thanks in advance! Regards, Aaron |
|
|
Hi Aaron,
I'm using the second one. The PostgreV2. I did have to fix something http://bugs.squeak.org/view.php?id=3834 to use it with Glorp. If you are looking for simple and you don't mind throwing your own SQL it couldn't be easier. All you do is connect and then send aConn execute: aSQLStatement. If you do use Glorp then it does all the mapping for you. You do need to load MD5 from the cryptography package. See www.squeaksource.com/Cryptography.html . Ron Teitelbaum Squeak Cryptography Team Leader > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Aaron Reichow > Sent: Wednesday, April 18, 2007 7:50 PM > To: The general-purpose Squeak developers list > Subject: Which PostgreSQL client? > > Hola! > > Just curious- what PostgreSQL client do you folks here on the list > recommend? There seem to be two implementations: > > > http://www.io.com/~jimm/projects/squeak_postgresql/ > > and > > http://ca.geocities.com/zazu@.../pgsqueak/ > (though a newer version is on SM here: http://map.squeak.org/package/ > a8d3ca99-f5f4-45e0-9aa7-100a77b64f45/autoversion/3) > > Any thoughts on which might be better? > > I'm going to use it for writing reports, drawing from info we have in > a PG db. I had to write a couple in Python, but I've gotten the go > ahead to do my new ones in Squeak. I've been using the pg module for > Python, and for writing reports I appreciate the simplicity, compared > to the full-blown PyGreSQL package. I'm not using this for a web app > or anything too hardcore- my co-worker or I run them periodically. > > I mention how I'll be using it because the usual considerations for a > decision like this- speed, SSL support, etc- take a back-seat to how > easy to use the API is. > > Thanks in advance! > > Regards, > Aaron > |
|
|
Ron,
Thanks for the reply! That sounds pretty handy, so I'll give it a try. Another consideration is that I am currently using Squeak 3.4. However, there is no need to use that per se, so if you have any recommendations as to which image version you think would be the best, I'm curious about that as well. No big reason to use 3.4 (as I do with my PDA/tablet work), I just have some images handy so I started working with that. OK, the following is long, but I describe it because I'm trying to find a way to take what is in the database and make objects out of it. I figured I would have to write up my own ORM setup, but I don't think that will be too hard. I hadn't thought of using Glorp, or something like it, and if what I describe below could be used with Glorp, please let me know! I won't be using Glorp, unfortunately. I assume that I can't use it with our database schema. That said, I really don't know that much about Glorp or similar systems, and I certainly wouldn't mind a little input on this either. The system I work on has this structure I've never used- sort of a simulated OODB. I imagine that this database design has been used before but it's the first time I've seen it. In short: TABLE RELATIONSHIP: id: integer = Unique ID for this row. compositeid: integer = The ID of the object pointing to the object represented in the row. componentid: integer= The ID of the object represented in the row. ikeywords: short string = The type/class of the item represented in the row. TABLE VALUE: id: integer = For certain ikeywords, the componentid of a row is here. value: string = The associated string value. Basically, the RELATIONSHIP table is nothing but pointers, along with the type/class information so our software knows what to do with it. It's pretty cool actually- it's a ton more flexible than most systems, it allows us to change our data model just like if we had an OODB. For instance, if we added a "nickname" field to our "person" object, we don't have to touch the database schema. As an example, this is what would be in the two tables to create a simple person: RELATIONSHIP: id compositeid componentid ikeywords -------- --------------- ---------------- ---------------- 99000 20000 30001 toperson [1] 99001 30001 30002 firstname 99002 30001 30003 lastname 99003 30001 30004 homenumber 99004 30004 30005 areacode 99005 30004 30006 phonenumber VALUE: id value -------- ------------- 30002 "Aaron" 30003 "Reichow" 30005 "612" 30006 "555-1212" Which could easily convert to a hash or object like so, all s-expy: (Person (Firstname, Lastname, Homenumber (AreaCode, PhoneNumber)))) [1] The root of our tree is 20000, so when you compositeid= 20000, you've connected the row/object to the root. Anyway, just in case anyone is bored and wondering about such things! :D Regards, Aaron On Apr 18, 2007, at 7:19 PM, Ron Teitelbaum wrote: > Hi Aaron, > > I'm using the second one. The PostgreV2. I did have to fix something > http://bugs.squeak.org/view.php?id=3834 to use it with Glorp. If > you are > looking for simple and you don't mind throwing your own SQL it > couldn't be > easier. All you do is connect and then send aConn execute: > aSQLStatement. > If you do use Glorp then it does all the mapping for you. > > You do need to load MD5 from the cryptography package. See > www.squeaksource.com/Cryptography.html . > > Ron Teitelbaum > Squeak Cryptography Team Leader > >> -----Original Message----- >> From: [hidden email] [mailto:squeak- >> dev- >> [hidden email]] On Behalf Of Aaron Reichow >> Sent: Wednesday, April 18, 2007 7:50 PM >> To: The general-purpose Squeak developers list >> Subject: Which PostgreSQL client? >> >> Hola! >> >> Just curious- what PostgreSQL client do you folks here on the list >> recommend? There seem to be two implementations: >> >> >> http://www.io.com/~jimm/projects/squeak_postgresql/ >> >> and >> >> http://ca.geocities.com/zazu@.../pgsqueak/ >> (though a newer version is on SM here: http://map.squeak.org/package/ >> a8d3ca99-f5f4-45e0-9aa7-100a77b64f45/autoversion/3) >> >> Any thoughts on which might be better? >> >> I'm going to use it for writing reports, drawing from info we have in >> a PG db. I had to write a couple in Python, but I've gotten the go >> ahead to do my new ones in Squeak. I've been using the pg module for >> Python, and for writing reports I appreciate the simplicity, compared >> to the full-blown PyGreSQL package. I'm not using this for a web app >> or anything too hardcore- my co-worker or I run them periodically. >> >> I mention how I'll be using it because the usual considerations for a >> decision like this- speed, SSL support, etc- take a back-seat to how >> easy to use the API is. >> >> Thanks in advance! >> >> Regards, >> Aaron >> > > > |
|
|
Hi Aaron,
What you have makes sense. There are other ways to accomplish the same thing but assuming that you want to stay with your schema then notice that your pointer table is really a collection of relationship objects. Considering that your mapping is relatively simple, to map this object you could certainly do it by hand (Mapping the resulting strings to values in a relationship object). Then you can model your behavior so that it creates the appropriate objects from your relationship objects and data values. Writing a parser to create objects should be relatively straight forward. The only problem that I see is partial data reads. This is not a problem if you are reading back values in an ordered structure, and if you read all values. This can really become a problem if you have a large object model, because you will quickly find out that retrieving one object means you need to instantiate the entire database. You should consider adding a proxy construct to represent relationships that have not been connected up yet. Then you can add the object linking behavior and/or data value lookup to the proxy objects. Also consider that much of the benefit of the DBMS is lost by your value table. It is possible to create views into your table that allow for indexing, and I assume that you left out an id that ties your values into a single object, but I would think that much is lost and indexing multiple views in a single table has a major performance implications which will not scale. You do gain some flexibility but that flexibility comes at a pretty big cost. There are better solutions to schema management. Regular Object Relational mapping would probably be better. Check out Glorp. I'm using 3.9 but I wouldn't assume that the code will not work in earlier versions. Try it and see. Hopefully if you load all the pieces it will work in any image. It is Smalltalk! Happy coding!! Ron Teitelbaum > -----Original Message----- > From: Aaron Reichow > > Ron, > > Thanks for the reply! > > That sounds pretty handy, so I'll give it a try. Another > consideration is that I am currently using Squeak 3.4. However, there > is no need to use that per se, so if you have any recommendations as > to which image version you think would be the best, I'm curious about > that as well. No big reason to use 3.4 (as I do with my PDA/tablet > work), I just have some images handy so I started working with that. > > OK, the following is long, but I describe it because I'm trying to > find a way to take what is in the database and make objects out of > it. I figured I would have to write up my own ORM setup, but I don't > think that will be too hard. I hadn't thought of using Glorp, or > something like it, and if what I describe below could be used with > Glorp, please let me know! > > I won't be using Glorp, unfortunately. I assume that I can't use it > with our database schema. That said, I really don't know that much > about Glorp or similar systems, and I certainly wouldn't mind a > little input on this either. The system I work on has this structure > I've never used- sort of a simulated OODB. I imagine that this > database design has been used before but it's the first time I've > seen it. In short: > > TABLE RELATIONSHIP: > id: integer = Unique ID for this row. > compositeid: integer = The ID of the object pointing to the object > represented in the row. > componentid: integer= The ID of the object represented in the row. > ikeywords: short string = The type/class of the item represented in > the row. > > TABLE VALUE: > id: integer = For certain ikeywords, the componentid of a row is here. > value: string = The associated string value. > > Basically, the RELATIONSHIP table is nothing but pointers, along with > the type/class information so our software knows what to do with it. > It's pretty cool actually- it's a ton more flexible than most > systems, it allows us to change our data model just like if we had an > OODB. For instance, if we added a "nickname" field to our "person" > object, we don't have to touch the database schema. As an example, > this is what would be in the two tables to create a simple person: > > RELATIONSHIP: > id compositeid componentid ikeywords > -------- --------------- ---------------- ---------------- > 99000 20000 30001 toperson [1] > 99001 30001 30002 firstname > 99002 30001 30003 lastname > 99003 30001 30004 homenumber > 99004 30004 30005 areacode > 99005 30004 30006 phonenumber > > VALUE: > id value > -------- ------------- > 30002 "Aaron" > 30003 "Reichow" > 30005 "612" > 30006 "555-1212" > > Which could easily convert to a hash or object like so, all s-expy: > > (Person (Firstname, Lastname, Homenumber (AreaCode, PhoneNumber)))) > > [1] The root of our tree is 20000, so when you compositeid= 20000, > you've connected the row/object to the root. > > Anyway, just in case anyone is bored and wondering about such things! :D > > Regards, > Aaron > > On Apr 18, 2007, at 7:19 PM, Ron Teitelbaum wrote: > > > Hi Aaron, > > > > I'm using the second one. The PostgreV2. I did have to fix something > > http://bugs.squeak.org/view.php?id=3834 to use it with Glorp. If > > you are > > looking for simple and you don't mind throwing your own SQL it > > couldn't be > > easier. All you do is connect and then send aConn execute: > > aSQLStatement. > > If you do use Glorp then it does all the mapping for you. > > > > You do need to load MD5 from the cryptography package. See > > www.squeaksource.com/Cryptography.html . > > > > Ron Teitelbaum > > Squeak Cryptography Team Leader > > > >> -----Original Message----- > >> From: [hidden email] [mailto:squeak- > >> dev- > >> [hidden email]] On Behalf Of Aaron Reichow > >> Sent: Wednesday, April 18, 2007 7:50 PM > >> To: The general-purpose Squeak developers list > >> Subject: Which PostgreSQL client? > >> > >> Hola! > >> > >> Just curious- what PostgreSQL client do you folks here on the list > >> recommend? There seem to be two implementations: > >> > >> > >> http://www.io.com/~jimm/projects/squeak_postgresql/ > >> > >> and > >> > >> http://ca.geocities.com/zazu@.../pgsqueak/ > >> (though a newer version is on SM here: http://map.squeak.org/package/ > >> a8d3ca99-f5f4-45e0-9aa7-100a77b64f45/autoversion/3) > >> > >> Any thoughts on which might be better? > >> > >> I'm going to use it for writing reports, drawing from info we have in > >> a PG db. I had to write a couple in Python, but I've gotten the go > >> ahead to do my new ones in Squeak. I've been using the pg module for > >> Python, and for writing reports I appreciate the simplicity, compared > >> to the full-blown PyGreSQL package. I'm not using this for a web app > >> or anything too hardcore- my co-worker or I run them periodically. > >> > >> I mention how I'll be using it because the usual considerations for a > >> decision like this- speed, SSL support, etc- take a back-seat to how > >> easy to use the API is. > >> > >> Thanks in advance! > >> > >> Regards, > >> Aaron > >> > > > > > > > |
|
|
Ron Teitelbaum wrote:
> I'm using 3.9 but I wouldn't assume that the code will not work in earlier > versions. Try it and see. Hopefully if you load all the pieces it will > work in any image. It is Smalltalk! If you need MD5 password authentication, then you'd need the Cryptography package to work in the Squeak version you want to use. Otherwise, the PostgresV2 package should work in older versions of Squeak. The original development was done around 2000/2001, in a then current Squeak (3.2? or was it 2.8?). Also, with some capatibility methods (mainly to do with networking), the basic postgres connection has worked in Spoon, VW/Cincom and VAST. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |