Hi all! I am developing an application with Seaside. I'd like to know what Squeak database is suggested in your own opinion and experience. I have tried Magma, but I cannot get it working in some special scenarios. For example Magma seems not supporting nested commits, so I cannot do something like:
(...into a callback of componentA...) magmaSession commit:[ self call: anotherComponent ].
(...into a callback of anotherComponent...) magmaSession commit:[ ...etc... ].
What are you using? Minnestore? MySql? Ciao ciao!
On Sun, 24 Aug 2003, Giovanni Giorgi wrote:
Hi all! I am developing an application with Seaside. I'd like to know what Squeak database is suggested in your own opinion and experience. I have tried Magma, but I cannot get it working in some special scenarios. For example Magma seems not supporting nested commits, so I cannot do something like:
(...into a callback of componentA...) magmaSession commit:[ self call: anotherComponent ].
(...into a callback of anotherComponent...) magmaSession commit:[ ...etc... ].
I think you'll find that particular feature is rare; offhand, I can't think of any database systems for Squeak that support it.
I would recommend OmniBase over Magma, however - it's had more time to prove its stability.
You might also look at PostgreSQL with either GLORP (for high level o/r mapping) or Roe (for lower level control).
On Sun, 2003-08-24 at 22:41, Avi Bryant wrote:
I think you'll find that particular feature is rare; offhand, I can't think of any database systems for Squeak that support it.
It's a valid concern, though. Any patterns around to deal with transactions around requests?
(I know we discussed this a while ago. But I always forget the outcome of such discussions if I don't apply it immediately :-))
On Mon, 25 Aug 2003, Cees de Groot wrote:
On Sun, 2003-08-24 at 22:41, Avi Bryant wrote:
I think you'll find that particular feature is rare; offhand, I can't think of any database systems for Squeak that support it.
It's a valid concern, though. Any patterns around to deal with transactions around requests?
(I know we discussed this a while ago. But I always forget the outcome of such discussions if I don't apply it immediately :-))
I think what you decided was that it was best to have one transaction per request - which is easy, just wrap the Session's request handling method with a transaction block. But I forget the exact rationale.
Can someone throw out some, um, "user stories" we can use to discuss this? What kinds of transactional scenarios are people interested in handling?
Avi
On Domenica, ago 24, 2003, at 22:41 Europe/Rome, Avi Bryant wrote:
[...] I think you'll find that particular feature is rare; offhand, I can't think of any database systems for Squeak that support it.
I would recommend OmniBase over Magma, however - it's had more time to prove its stability.
I also feel Magma a bit unstable.
The free version of Omnibase seems hard to be userful (no GC!). What about Minnestore? I know it well (I have done the port to VW 3.0) but I think magma is faster.
You might also look at PostgreSQL with either GLORP (for high level o/r mapping) or Roe (for lower level control).
So GLORP is a good solution?! Thank you a lot!
On Tue, 26 Aug 2003, Giovanni Giorgi wrote:
The free version of Omnibase seems hard to be userful (no GC!).
True, although I can imagine some applications where you don't want to throw away any data, ever, and that wouldn't be so bad. Also, I bet it would be fairly easy to write a "compress" routine that basically copied from one DB to another, which you could run every week or so... this might eliminate the need for GC. I wonder if David would consider this "cheating"?
What about Minnestore? I know it well (I have done the port to VW 3.0) but I think magma is faster.
I find Minnestore an odd beast - halfway between an OODB and O/R. Have you had good success with it?
It also doesn't seem to be very well maintained anymore, is that impression correct?
You might also look at PostgreSQL with either GLORP (for high level o/r mapping) or Roe (for lower level control).
So GLORP is a good solution?!
I've never used it in production. I've also grown somewhat wary (and weary) of that brand of O/R mapping (well, really of O/R mapping in general). But as these things go it seems pretty good.
Avi Bryant seaside@lists.squeakfoundation.org said:
True, although I can imagine some applications where you don't want to throw away any data, ever, and that wouldn't be so bad. Also, I bet it would be fairly easy to write a "compress" routine that basically copied from one DB to another, which you could run every week or so... this might eliminate the need for GC. I wonder if David would consider this "cheating"?
Probably :-).
In any case, we run OmniBase - have been in production with it for almost two years now - doing 10-20 transactions per second on average, 24x7. Disk prices come down faster than my urge to do a GC rises, I maybe run one twice a year, and only then because I'm too lazy to extend partitions or something like that. So I wouldn't call it too big a handycap.
I've never used it in production. I've also grown somewhat wary (and weary) of that brand of O/R mapping (well, really of O/R mapping in general). But as these things go it seems pretty good.
Exactly the right statement and sentiment - as O/R tools go, Glorp is ok.
However, you must be prepared to dive into it. First, it is not documented very well, second, it has bugs&quirks that you must be prepared to hack away.
Personally, I decided on the persistence mechanism called 'Smalltalk saveSession' once an hour for my projects, certainly until they stabilize enough to let me bother about persistence. By that time, I will probably choose OmniBase for it.
On Martedì, ago 26, 2003, at 22:26 Europe/Rome, Avi Bryant wrote:
[...]
What about Minnestore? I know it well (I have done the port to VW 3.0) but I think magma is faster.
I find Minnestore an odd beast - halfway between an OODB and O/R. Have you had good success with it?
I have done the SIForge wizard with it and it works well.
It also doesn't seem to be very well maintained anymore, is that impression correct?
The original author cannot mantain it anymore. I know the dolphin port was active, but the mailing list seems dead. I fear someone is using it and nobody is mantain it at this time. So OmniBase is an interesting product? It is used/good?
Its pretty good. It has some holes but for the simple cases it handles it works quite well. What doesn't work so well are many-to-many relationships and the ability to qualify queries based on relationship criteria. Also no relationship delete rules. Its made a lot easier to use with the EO extensions using EOModels.
-Todd Blanchard
On Tuesday, August 26, 2003, at 01:37 PM, Giovanni Giorgi wrote:
So GLORP is a good solution?! Thank you a lot!
seaside@lists.squeakfoundation.org said:
Its pretty good. It has some holes but for the simple cases it handles it works quite well. What doesn't work so well are many-to-many relationships and the ability to qualify queries based on relationship criteria.
That's probably all true for the Squeak port - I don't know how old it is, but at work I use the most up-to-date VW version and m:n relations, relational queries, etcetera all work well. It even has binding syntax which in some databases is necessary to store large objects and generally is better for performance.
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Cees de Groot -
cg＠cdegroot.com
-
Giovanni Giorgi -
tblanchard＠mac.com