Glorp/Seaside experience exchange on- or offline, anybody?
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 mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Hi guys
We (the pharo team) are really interested. This is why the consortium invested in a documentation and this is why I spent time editing it
it is now available in the booklet collection available at http://books.pharo.org
This is also we paid to get the Garage library.
Remember that we are interested in fostering business :).
Please please if you write some docs let me know and we can integrate them in the Glorp booklet.
I would like to know
- how to connect Glorp and Magritte (I’m revisiting the Magritte tutorial and soon the implementation)
- how to could we have a simple CRUD on top of Glorp/Magritte
- how can we reduce the verbosity of Glorp
- Can we have better tooling?
If people want to come to lille we have pay the beers and also host event?
I would like to migrate the Seaside online book into an open-source pillar version (but I have another book on the grill and many things).
We should continue to maintain the Seaside documentation and grow it.
Stef
On 28 Sep 2017, at 08:56, jtuchel@objektfabrik.de 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.
Where is it?
Because on Pharo it is super simple: http://books.pharo.org
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 mailto:jtuchel@objektfabrik.de mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de http://www.objektfabrik.de/
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com http://joachimtuchel.wordpress.com/
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
Hi
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.
Cheers
Philippe
On Thu, Sep 28, 2017 at 8:56 AM, jtuchel@objektfabrik.de
jtuchel@objektfabrik.de 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 mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
seaside mailing list
seaside@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
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.
Steve
From: Philippe Marschallmailto:philippe.marschall@gmail.com
Sent: 01/10/2017 22:41
To: Seaside - general discussionmailto:seaside@lists.squeakfoundation.org
Cc: esug-list@lists.esug.orgmailto:esug-list@lists.esug.org; glorp-groupmailto:glorp-group@googlegroups.com
Subject: Re: [Esug-list] [Seaside] Glorp/Seaside experience exchange on- or offline, anybody?
Hi
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.
Cheers
Philippe
On Thu, Sep 28, 2017 at 8:56 AM, jtuchel@objektfabrik.de
jtuchel@objektfabrik.de 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 mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
seaside mailing list
seaside@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi Phillip,
On 10/1/2017 1:40 PM, Philippe Marschall wrote:
Hi
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.
As an object-relational mapping framework, Glorp has no way to know
which retrieved objects are going to be modified. If you don't cache
objects on retrieval, you have to go back to the database again to see
what's changed before doing an update. Also, if the application has a
simple UI with lots of objects which are not modified, but are used
continually, it may make sense to keep them around. In any case,
retrieving objects that are read-only in one session and potentially
editable objects in another session and then flushing caches at
appropriate times might be appropriate.
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.
Philippe, I think your "it should be this way" could be right for some
applications, but wrong for others. A solution for an application that
serves one request at a time per image with multiple images running in
parallel might do things the way you suggest. Another application might
want to cache objects in the image for use by multiple simultaneous
requests. If you register retrieved objects only when the edit button is
clicked, you need an extra round trip to the database. It might depend
on whether your limited resource is the database server, application
server memory, application server cpu or something else.
Cincom uses Glorp to read and write source code definitions in StORE.
When reading, Store database objects are retrieved and then converted to
active Smalltalk code. When writing a package or bundle, the Store
database objects have to be synched to the database before writing a new
version so that unchanged definitions are not written as duplicates in
the database. This is, in essence, what you're suggesting. It's
necessary because the objects in the image live long beyond the duration
of a database connection, but it has a cost.
Hope you find this helpful...
I would also be open to attending some sort of meetup in northern
Switzerland/southern Germany to discuss this in person.
Cheers
Philippe
On Thu, Sep 28, 2017 at 8:56 AM, jtuchel@objektfabrik.de
jtuchel@objektfabrik.de 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 mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
seaside mailing list
seaside@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Dear Joachim,
I'm interested. It would be good to pull together the existing
documentation, address gaps (and areas where what we have is not clear),
and ensure people know of fixes and patterns - I have had to solve
issues with the polymorphic joins and embedded objects you mention, with
conditionals, etc. An application-driven approach is a good idea:
specific how-to queries arising from specific needs.
For myself, I might find a more northerly location - e.g. Belgium - a
tad easier, but you could doubtless say the same in reverse (and who
knows which location will have easiest/cheapest flights, whatever.). A
Skype call - even a Skype call for some, while other attenders are
meeting face to face - is doable, and I'd certainly attend that way if
in no other.
As Tom notes in his discussion of Phillippe Marschall's points, either
you let Glorp manage the caches and accept some memory load, or you
re-read, or you tell Glorp to trust your in-image bridging between units
of work - which is a possible pattern, but of course loaded with danger
if you could be wrong. Studying patterns for managing this could be
interesting (being aware, of course, that some of them come with
historical baggage).
Meanwhile, I will remark that. while I quite see what you mean about
writing huge messages to newsgroups, I do not mind personally receiving
long emails on Glorp specifics and, on the timescale that other tasks
and deadlines allow, will read them with interest.
Yours faithfully
Niall Ross
jtuchel@objektfabrik.de 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 mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Hi there,
I must say I like the way this discussion is evolving. Just too bad it
is spread over multiple groups (but that is my fault).
So it seems people prefer to keep discussing on mailing lists rather
than spend time meeting in person or virtually.
Let me start with a topic that I am still not sure I understand:
For quite a while, we used a patched version of
#commitUntOfWorkAndContinue in order to be able to use objects once
loaded in a session after a commit or rollback without having to re-read
them.
But this seemed to bloat images, because caches were growing and
growing. And we ran into the old problem of "why can't user B see user's
A's changes?". But since our object graphs can get big, we stuck with
commitUnitOfWorkAndContinue and rollbackUnitOfWorkAndContinue. Until
users complained about or slow server.
So I made this experiment:
obj := session read: MyClass where: [:ea| ea id = 1000].
obj someVariable: 50.
session commitUnitOfWork; beginUnitOfWork.
session refresh: obj.
obj someVariable: 30.
session commitUnitOfWork.
obj inspect.
I had expected this to fail miserably. I wasn't sure about whether it
would fail at the first #refresh: or if the following commit would
either fail or do an INSERT instead of an UPDATE.
Surprisingly, the snippet worked. Not only did both commits correctly
issue UPDATEs, the values in the object were correct at all times.
My initial theory about this would be that after a commitUnitOfWork, the
object in the image would be "detached" from the DB. But it isn't.
I still can hardly believe it and would like to know if that is by
design or accident.
The refresh: is not necessary for the followng commint to understand it
needs to Update, it is more to reflect changes that have been made in
the DB since we read the object from the DB.
Still this feels a bit strange and I wonder if we are living on a
coincidence here or if this is intended behavior.
Any thoughts?
Joachim
--
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1