I’ll have to give this a shot on VW and see what I might run into on that platform.. Obviously I’ve got a different Glorp backend to deal with (no SequakDatabaseAccessor — it’s a VWDatabaseAccessor IIRC) which I know has a different “look” to it.. I had a connection pool I got from someone else that was written for Squeak and gave up on getting it to work w/ Glorp on VW — too much down in the bowels of Glorp and my infamiliarity with those bowels.. (8-

I’ve already been lurking on the Glorp mailing list for a while, even posted once or twice, and I’ll post more about my experiences as I find time. Right now, I’m busy working on my own ActiveRecord derived from Magritte meta data. If I run into any serious problems, you can bet I’ll post questions to the list.

Thanks for the idea, I’ll have a go at retrofitting some older applications of mine to see how that pooling interferes with unusual user interactions.

Also. it would be cool if you could join us on the glorp mailing list, I’m sure Alan would be more than interested in hearing from your experiences.

Regards, mjl

matches =
SomeClass.find :all,
:limit => 15,
:conditions => proc { |each| each.timestamp != DateTime.now },
:order => proc { |each| each.timestamp.descending }

matches =
    SomeClass.find :all,
        :limit => 15,
        :conditions => proc { |each| each.timestamp  proc { |each| each.timestamp.descending }

Of course, Rails doesn’t support that as of today (as far as I know), but It would be possible. In fact, part of the Rails validation protocol uses something similar for validation.

So I think it’s going to confuse Glorp a lot if you read object X from session A, modify it and write it on session B.

Also, you’ll lose identity, the same object will be instanciated several times from different sessions, so what happens when you change instance 1 of object X but later on use instance 2?

Regards, mjl

>Just a question, is Glorp only on squeakmap ?

Alan Knight develops Glorp on Cincom VisualWorks and it will eventually (soon) become Cincom’s official persistence framework. So if you install a current version of VisualWorks (for download of non commercial version see http://www.cincomsmalltalk.com) you will also get Glorp along with it. Additionally, the most up-to-date code for VisualWorks can be found on the Cincom Public Store Repository (for setting up access see also http://www.cincomsmalltalk.com).

Hope this helps,
Paul

Nor does Rails use native Ruby syntax (I should have said “style”) for its queries.

matches =
    SomeClass.find(:all,
        :limit => 15,
        :conditions => "timestamp < now()",
        : order => “timestamp desc”)

That’s not native, that’s passing pieces of sql in strings as associations, not at all how you’d query a collection in memory using the each method and a block.

Glorp actually uses native Smalltalk syntax, i.e. blocks, not sql in strings. In Glorp, I could write like this…

matches := session execute:
    (SomeClass findAll
        limit: 15;
        where:[:each | each timestamp < TimeStamp now];
        orderBy: [:each | each timestamp descending])

And in Glorp, queries are actually composable objects, so I can compose complicated queries, unions, joins, sub-queries, all in Smalltalk without dropping into sql, Rails makes you drop into sql. ]]> http://onsmalltalk.com/programming/smalltalk/seaside/making-a-connection-pool-for-glorp-in-seaside/#comment-818 Ronaldo Thu, 11 Jan 2007 15:13:41 +0000 http://onsmalltalk.com/general/making-a-connection-pool-for-glorp-in-seaside/#comment-818 One thing that always strikes me about Smalltalk code is how beautiful it is. Going back to .NET or something else is always hard to do after coding on it for a while. GLORP is really nice. "It’ll do things Rails couldn’t dream of as far as mapping and querying goes, and it does it in native Smalltalk syntax." That, however, is misleading and unqualified. It would be interesting to see at least one example of it, especially considering that Rails uses Ruby syntax in the same way Glorp uses Smalltalk syntax. One thing that always strikes me about Smalltalk code is how beautiful it is. Going back to .NET or something else is always hard to do after coding on it for a while. GLORP is really nice.

“It’ll do things Rails couldn’t dream of as far as mapping and querying goes, and it does it in native Smalltalk syntax.”

That, however, is misleading and unqualified. It would be interesting to see at least one example of it, especially considering that Rails uses Ruby syntax in the same way Glorp uses Smalltalk syntax.

Just a question, is Glorp only on squeakmap ?

See you

Cédrick