Re: [Seaside] Glorp/Seaside experience exchange on- or offline, anybody?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [Seaside] Glorp/Seaside experience exchange on- or offline, anybody?

Steven Kelly
What about caching reads for performance reasons? That seems useful in GLORP for Store, or am I just imagining it? I have images that have lived for years and haven't slowed down or become bloated, so GLORP caches are clearing correctly when the image is saved, restarts and reconnects to Store.

I have a little home grown ORM and web renderer that does no caching, and that too works fine: in simple old-fashioned web rendering, you rarely would want to cache longer than it takes to render one page.


From: [hidden email]
Sent: ‎01/‎10/‎2017 22:41
To: [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Esug-list] [Seaside] Glorp/Seaside experience exchange on- or offline, anybody?


Let me start by mentioning that I don't believe any of these issues
are Seaside specific. IMO these issues apply to any web framework
using GLORP and even any web framework using an ORM in general. So it
could be beneficial to investigate how other Smalltalk web frameworks
(AIDA, ApeX, Iliad, ...) or even other languages solve this issue
(JSF, Spring Web MVC, JPA/Hibernate).

What is most concerning to me is how every object ever loaded with
GLOP is tracked in the cache of the GLOP session. IMO this is wrong as
most objects are read-only and never edited. These objects should not
be tracked. This leads to a lot of unnecessary memory overhead. Only
the objects that are actually edited should be tracked.
I think of it this way, when a table or list of objects is rendered
none the displayed objects should be tracked. Only when an edit link
or button is clicked and an edit form is rendered then the edited
object needs to be tracked and optimistically locked. If we track
every object ever loaded then this simply leads to unbound memory
usage. If caching has to happen for correctness then the cache should
be flushed at the end of a request.

Digging a bit into the GLROP documentation I don't think a unit of
work should be active during the render phase. As far as I understand
this should prevent any of the loaded objects from being tracked by
being added to the cache. Only when an object is being edited should
it be registered manually for tracking by the GLOP session.
However during the callback phase a unit of work should be active.
This should be done automatically by a Seaside-GLORP extension. On a
successful or cancelled edit the edited object should be removed from
the cache again and the callback should be invalidated (ideally a one
time callback is used).

It would be good to hear from somebody with GLROP experience whether
what I just wrote made any sense at all or is utter nonsense.

I would also be open to attending some sort of meetup in northern
Switzerland/southern Germany to discuss this in person.


On Thu, Sep 28, 2017 at 8:56 AM, [hidden email]
<[hidden email]> wrote:
> Hi there,
> since nobody at ESUG seemed to be interested in a Glorp/Seaside BOF as I
> suggested, I try something new now ;-)
> Glorp is a great tool for OR mapping and works very well. There is good
> introductory material, even if it is hard to find. But when it comes to real
> world use, there are many questions to be answered like
> how to handle transactions, mementos, units of work and that stuff,
> especially in a multi-user environment like a Seaside based web app
> how to map more complicated things, like polymorphic joins, embedded objects
> etc.
> what if an image slows down gradually when a user has been working for
> hours, almsot coming to a standstill. How to find out if Glorp or your use
> of it is the problem? What can you do then?
> Is my use of transactions correct or will I face problems
> None of these are easy questions and maybe there are many possible answers
> to them, But finding them on your own can be hard and take a lot of time. It
> can even be a risk to your business.
> There is the Glorp group, but it's not actually in heavy use and sometimes
> it is hard to write down a problem in a few lines. Explaining the whole
> thing sometimes would make for loooong messages that probably nobody ever
> reads, esp. if the poster's english isn't brilliant.
> So what I'm looking for is ways to find and meet people who also use Glorp
> (or any other ORM in Smalltalk) and would be interested in discussing stuff
> and maybe answer questions. Something like a Glorp users group.
> The best thing to exchange ideas is probably to meet face to face and carry
> your laptop with you. So if anybody in Southern Germany, Eastern France,
> Northern Switzerland would be interested in such a meeting, please let me
> know and I am more than interested in setting something up.
> The second best is probably some sort of online conference call. Maybe even
> on a regular basis.
> Please let me know if you'd be interested.
> Joachim
> --
> -----------------------------------------------------------------------
> Objektfabrik Joachim Tuchel          [hidden email]
> Fliederweg 1               
> D-71640 Ludwigsburg        
> Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
> _______________________________________________
> seaside mailing list
> [hidden email]

Esug-list mailing list
[hidden email]

Esug-list mailing list
[hidden email]