Which are the main packages for accessing SQL databases and business applications in general, like reports, printing, forms generation etc?
Frank
On Mon, Mar 23, 2009 at 7:48 AM, Frank Church vfclists@googlemail.comwrote:
Which are the main packages for accessing SQL databases
I can talk about persistence only. First of all, this link has the database alternatives for squeak: http://wiki.squeak.org/squeak/512. AFAIK Squeak has, natively, only drivers for PostgreSQL and MySQL. That's about drivers. But, I think you don't want to write a insert by hand, and you would rather use a ORM (If you cannot use a OODBMS). In this case, the ORM is Glorp. The problem with Glorp is that the port of it to Squeak is totally hardcoded with PostgreSQL driver.
In summary - At driver level you have: PostgreSQL and MySQL - At ORM level, you only have PostgreSQL.
That's why we developed (and we are still developing) SqueakDBX. With it, you can talk with mayor databases like PostgreSQL, MySQL, Oracle, SQL Server, Sqlite3, and so on. Our wiki page is this: http://wiki.squeak.org/squeak/6052.
We have two beta releases till now and this month we will release our first stable version. Here you can see the supported backends in the different OS: http://wiki.squeak.org/squeak/6108
We have done lots of tests and benchmarks. Benchmarks shows SqueakDBX is faster that the PostgreSQL native driver. We are know comparing to MySQL native driver also. Here are the benchmarks: http://wiki.squeak.org/squeak/6063
And finally, we are starting to modify Glorp (the Squeak port) and put a common interfaze between Glorp - Any Driver. So, any driver could easily used. We are going to create the PostgreSQL native driver and a SqueakDBX driver.
That's all. If you have any doubt, question, suggestion or feeback with SqueakDBX, please let me know.
Cheers,
Mariano
and business applications in general, like reports, printing, forms generation etc?
Frank
Hi!
Mariano Martinez Peck wrote:
That's why we developed (and we are still developing) SqueakDBX. With it, you can talk with mayor databases like PostgreSQL, MySQL, Oracle, SQL Server, Sqlite3, and so on.
[SNIP lots of nice info]
First of all - I really like the SqueakDBX project because it fills a hole that has been largely empty for quite some time and is very important in many projects. So having a good SqueakDBX will surely open up more uses for Squeak. Kudos!
Secodnly - the original question was about SQL and how to access legacy stuff I think, but there are several new interesting database alternatives around that is worth mentioning. I have toyed with two of them lately:
CouchDB. The "new hip" db in town. There is a working API on SqueakSource for it that uses the Curl plugin. I have also written a so called "view server" for Squeak so that you can define server side "views" in Squeak instead of Javascript. CouchDB is a very, very interesting piece of software. Kinda like an OODB but in web2.0 style with a REST API and JSON as native "object" format.
TokyoCabinet/TokyoTyrant. Another of these new hip dbs, although a lurker. Developed and used by "Japanese facebook" mixi.jp. It is a very attractive and extremely performant database with lots of cool features. I just published a first "almost complete" implementation of its binary Socket protocol on SS, project "TokyoTyrant".
Enough rant. :) I just find these new beasts to be "fresh air". For an example on how terribly easy it is to use TokyoTyrant:
1. Download and install TokyoCabinet and TokyoTyrant. There are packages and the "./configure; make; make install"-dance worked perfectly for me.
2. Start a vanilla TokyoTyrant server: Just type "ttserver" and press enter.
3. Install "TokyoTyrant" from SS. Then try a doit:
| db | "This opens localhost:1978 by default" db := TokyoTyrantDB new. db open.
"Store a value at a key, will be converted to ByteArrays before stored" db at: 'key' put: 'my little value'.
"Fetch value, if we use #at: we get a ByteArray back" db stringAt: 'key'
There is also a test suite that should be green given that you started "ttserver" first. Note that the above is just a little bit of the API.
regards, Göran
Göran Krampe wrote:
Secodnly - the original question was about SQL and how to access legacy stuff I think, but there are several new interesting database alternatives around that is worth mentioning. I have toyed with two of them lately:
Interesting. When would you prefer either of them over a plain old SQL database? I'm not familiar with either CouchDB or TokyoCabinet/TokyoTyrant but I'd be interested to find out more about their application areas.
Cheers, - Andreas
Hi!
(I almost missed this one, sorry)
Andreas Raab wrote:
Göran Krampe wrote:
Secodnly - the original question was about SQL and how to access legacy stuff I think, but there are several new interesting database alternatives around that is worth mentioning. I have toyed with two of them lately:
Interesting. When would you prefer either of them over a plain old SQL database? I'm not familiar with either CouchDB or TokyoCabinet/TokyoTyrant but I'd be interested to find out more about their application areas.
Let me give you a quick take on this rather large subject :). First, a summary of my little efforts on both these products:
- I toyed with CouchDB, there was already a Curl-based API at SS for it. I also implemented a "view server" in Squeak for it, haven't released it yet, should do that. I track it, it moves. It's hip.
- I recently started playing with TT/TC and have built a Squeak API for it, I just threw it up on SM and yesterday I posted a lengthy blog article about it in fact:
http://goran.krampe.se/blog/Squeak/TokyoTyrant.rdoc
History:
- Most of these new dbs have been built as responses to pragmatic needs to scale a LOT. TT/TC comes from Mixi.jp ("Facebook of Japan"). Then you have a whole list of these things from Amazon (Dynamo - closed), Google (BigTable), Facebook (Cassandra) etc etc.
- CouchDB is also built to scale like crazy, but started as a single man hobby project. It is one of the few projects with a really strong developer community since it was NOT built inside a company. Built in Erlang as are MANY of these new dbs.
Back to the reasons why one would prefer them (any of these), my take on it:
1. Peformance/hardware ratio. Most of these are variants of "key-value stores" or "document centric dbs". They focus a lot on speed. As you can see in my blog entry TT/TC is awfully fast, well, I haven't compared yet to say PGSQL, but I can't imagine doing 2000-3000 inserts/sec stuffing 18Mb/sec into an SQL db on this little mini laptop of mine. I really hope I am not lying through my teeth. :)
2. Avoid the ORM/"impedance mismatch" swamp. CouchDB is a key-value store which stores JSON objects (a "document" in their lingo). Thus it can store/load object graphs/hierarchies in one "clump" quite easily - so in some respect these databases are similar to OODBs IMHO. TT/TC stores "more or less" binary blobs (unless you use table extension).
3. Dynamics. Both CouchDB and TT/TC (using table extension) talk about a "schema less" model. This translates to the fact that CouchDB can store *any* JSON object, there is no schema. And using map/reduce you can still work with "views" on them etc. TT/TC using table extension more or less stores a Dictionary as value: "<key> $00 <value> $00 <key2> $00 <value2>". And then it has support for adding indexes on these keys, a query engine, a Lua scripting extension inside TT to do "stored procedures"-stuff etc. But key here is the fact that these databases are made to deal with a changing world and does not rely on strict schemas nor advanced types, and when you have it running on say 100 servers these aspects seem to become very important (not talking from experience, just from what I hear in these forums).
4. Scale horisontally. A lot. CouchDB aims at mega-scaling using replication and multi-version logic - "eventual consistency". It also implements the map/reduce pattern where you can define map and reduce functions in JS running on the server in a so called "view server". TT/TC also has replication, dual-master failover, single-master-multi-readers etc. It does not have mega-scaling goals as CouchDB has, but there are already "layers on top" like LightCloud that forms a hash-ring of TT/TC servers for scaling. And since it is so darn fast on a single box it covers a lot of use cases without large scaling.
From a more personal "touchy feely" perspective these things (and several others like Dynomite) are a fresh air! They are very simple to use. They are FAST. They are robust. They are small. They often embrace the "web 2.0" world by using JSON, HTTP-REST APIs, memcached protocol etc etc.
For the moment I am focusing on TT/TC but CouchDB has some very interesting things going for it - like Erlang OTP, promised transparent replication and its map/reduce stuff. And the CouchDB API on SS seems to work fine if you get the Curl plugin.
Well, that turned into a long post, but hopefully I answered some of it. For more details read my blog article! :) I also plan to write another soon about the table extension and its Lua mechanisms.
regards, Göran
On 3/28/09 7:06 AM, "Göran Krampe" goran@krampe.se wrote:
Hi!
(I almost missed this one, sorry)
Andreas Raab wrote:
Göran Krampe wrote:
Secodnly - the original question was about SQL and how to access legacy stuff I think, but there are several new interesting database alternatives around that is worth mentioning. I have toyed with two of them lately:
Interesting. When would you prefer either of them over a plain old SQL database? I'm not familiar with either CouchDB or TokyoCabinet/TokyoTyrant but I'd be interested to find out more about their application areas.
Let me give you a quick take on this rather large subject :). First, a summary of my little efforts on both these products:
- I toyed with CouchDB, there was already a Curl-based API at SS for it.
I also implemented a "view server" in Squeak for it, haven't released it yet, should do that. I track it, it moves. It's hip.
- I recently started playing with TT/TC and have built a Squeak API for
it, I just threw it up on SM and yesterday I posted a lengthy blog article about it in fact:
http://goran.krampe.se/blog/Squeak/TokyoTyrant.rdoc
History:
- Most of these new dbs have been built as responses to pragmatic needs
to scale a LOT. TT/TC comes from Mixi.jp ("Facebook of Japan"). Then you have a whole list of these things from Amazon (Dynamo - closed), Google (BigTable), Facebook (Cassandra) etc etc.
- CouchDB is also built to scale like crazy, but started as a single man
hobby project. It is one of the few projects with a really strong developer community since it was NOT built inside a company. Built in Erlang as are MANY of these new dbs.
Back to the reasons why one would prefer them (any of these), my take on it:
- Peformance/hardware ratio. Most of these are variants of "key-value
stores" or "document centric dbs". They focus a lot on speed. As you can see in my blog entry TT/TC is awfully fast, well, I haven't compared yet to say PGSQL, but I can't imagine doing 2000-3000 inserts/sec stuffing 18Mb/sec into an SQL db on this little mini laptop of mine. I really hope I am not lying through my teeth. :)
- Avoid the ORM/"impedance mismatch" swamp. CouchDB is a key-value
store which stores JSON objects (a "document" in their lingo). Thus it can store/load object graphs/hierarchies in one "clump" quite easily - so in some respect these databases are similar to OODBs IMHO. TT/TC stores "more or less" binary blobs (unless you use table extension).
- Dynamics. Both CouchDB and TT/TC (using table extension) talk about a
"schema less" model. This translates to the fact that CouchDB can store *any* JSON object, there is no schema. And using map/reduce you can still work with "views" on them etc. TT/TC using table extension more or less stores a Dictionary as value: "<key> $00 <value> $00 <key2> $00 <value2>". And then it has support for adding indexes on these keys, a query engine, a Lua scripting extension inside TT to do "stored procedures"-stuff etc. But key here is the fact that these databases are made to deal with a changing world and does not rely on strict schemas nor advanced types, and when you have it running on say 100 servers these aspects seem to become very important (not talking from experience, just from what I hear in these forums).
- Scale horisontally. A lot. CouchDB aims at mega-scaling using
replication and multi-version logic - "eventual consistency". It also implements the map/reduce pattern where you can define map and reduce functions in JS running on the server in a so called "view server". TT/TC also has replication, dual-master failover, single-master-multi-readers etc. It does not have mega-scaling goals as CouchDB has, but there are already "layers on top" like LightCloud that forms a hash-ring of TT/TC servers for scaling. And since it is so darn fast on a single box it covers a lot of use cases without large scaling.
From a more personal "touchy feely" perspective these things (and several others like Dynomite) are a fresh air! They are very simple to use. They are FAST. They are robust. They are small. They often embrace the "web 2.0" world by using JSON, HTTP-REST APIs, memcached protocol etc etc.
For the moment I am focusing on TT/TC but CouchDB has some very interesting things going for it - like Erlang OTP, promised transparent replication and its map/reduce stuff. And the CouchDB API on SS seems to work fine if you get the Curl plugin.
Well, that turned into a long post, but hopefully I answered some of it. For more details read my blog article! :) I also plan to write another soon about the table extension and its Lua mechanisms.
regards, Göran
Goran:
This report is very useful. As some new community blog is around the corner, this and other could have a copy on it ?
Same for other post to this list , if all members have a quick view of Masters opinion in the same place...
Edgar
On Sat, 2009-03-28 at 09:19 -0300, Edgar J. De Cleene wrote:
Goran:
This report is very useful. As some new community blog is around the corner, this and other could have a copy on it ?
Same for other post to this list , if all members have a quick view of Masters opinion in the same place...
Edgar
Perhaps I'm missing the point, it wouldn't be the first time, but we already have http://planet.squeak.org/ and Goran's blog has appeared there for some time, along with others.
Ken
Wow. What a fascinating read. Thanks so much. How's tool support for these dbs? One of the major reasons for us going with MySQL was simply because of tool support (i.e., management can extract the relevant numbers like new user signups, usage hours, growth curve, etc for themselves). Turns out this is just as important as the technical details ;-)
Cheers, - Andreas
Göran Krampe wrote:
Hi!
(I almost missed this one, sorry)
Andreas Raab wrote:
Göran Krampe wrote:
Secodnly - the original question was about SQL and how to access legacy stuff I think, but there are several new interesting database alternatives around that is worth mentioning. I have toyed with two of them lately:
Interesting. When would you prefer either of them over a plain old SQL database? I'm not familiar with either CouchDB or TokyoCabinet/TokyoTyrant but I'd be interested to find out more about their application areas.
Let me give you a quick take on this rather large subject :). First, a summary of my little efforts on both these products:
- I toyed with CouchDB, there was already a Curl-based API at SS for it.
I also implemented a "view server" in Squeak for it, haven't released it yet, should do that. I track it, it moves. It's hip.
- I recently started playing with TT/TC and have built a Squeak API for
it, I just threw it up on SM and yesterday I posted a lengthy blog article about it in fact:
http://goran.krampe.se/blog/Squeak/TokyoTyrant.rdocHistory:
- Most of these new dbs have been built as responses to pragmatic needs
to scale a LOT. TT/TC comes from Mixi.jp ("Facebook of Japan"). Then you have a whole list of these things from Amazon (Dynamo - closed), Google (BigTable), Facebook (Cassandra) etc etc.
- CouchDB is also built to scale like crazy, but started as a single man
hobby project. It is one of the few projects with a really strong developer community since it was NOT built inside a company. Built in Erlang as are MANY of these new dbs.
Back to the reasons why one would prefer them (any of these), my take on it:
- Peformance/hardware ratio. Most of these are variants of "key-value
stores" or "document centric dbs". They focus a lot on speed. As you can see in my blog entry TT/TC is awfully fast, well, I haven't compared yet to say PGSQL, but I can't imagine doing 2000-3000 inserts/sec stuffing 18Mb/sec into an SQL db on this little mini laptop of mine. I really hope I am not lying through my teeth. :)
- Avoid the ORM/"impedance mismatch" swamp. CouchDB is a key-value
store which stores JSON objects (a "document" in their lingo). Thus it can store/load object graphs/hierarchies in one "clump" quite easily - so in some respect these databases are similar to OODBs IMHO. TT/TC stores "more or less" binary blobs (unless you use table extension).
- Dynamics. Both CouchDB and TT/TC (using table extension) talk about a
"schema less" model. This translates to the fact that CouchDB can store *any* JSON object, there is no schema. And using map/reduce you can still work with "views" on them etc. TT/TC using table extension more or less stores a Dictionary as value: "<key> $00 <value> $00 <key2> $00 <value2>". And then it has support for adding indexes on these keys, a query engine, a Lua scripting extension inside TT to do "stored procedures"-stuff etc. But key here is the fact that these databases are made to deal with a changing world and does not rely on strict schemas nor advanced types, and when you have it running on say 100 servers these aspects seem to become very important (not talking from experience, just from what I hear in these forums).
- Scale horisontally. A lot. CouchDB aims at mega-scaling using
replication and multi-version logic - "eventual consistency". It also implements the map/reduce pattern where you can define map and reduce functions in JS running on the server in a so called "view server". TT/TC also has replication, dual-master failover, single-master-multi-readers etc. It does not have mega-scaling goals as CouchDB has, but there are already "layers on top" like LightCloud that forms a hash-ring of TT/TC servers for scaling. And since it is so darn fast on a single box it covers a lot of use cases without large scaling.
From a more personal "touchy feely" perspective these things (and several others like Dynomite) are a fresh air! They are very simple to use. They are FAST. They are robust. They are small. They often embrace the "web 2.0" world by using JSON, HTTP-REST APIs, memcached protocol etc etc.
For the moment I am focusing on TT/TC but CouchDB has some very interesting things going for it - like Erlang OTP, promised transparent replication and its map/reduce stuff. And the CouchDB API on SS seems to work fine if you get the Curl plugin.
Well, that turned into a long post, but hopefully I answered some of it. For more details read my blog article! :) I also plan to write another soon about the table extension and its Lua mechanisms.
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Edgar J. De Cleene -
Frank Church -
Göran Krampe -
Ken Causey -
Mariano Martinez Peck