Smalltalk › Frameworks & Tools › GLORP

Glorp/Seaside experience exchange on- or offline, anybody?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

jtuchel

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          [hidden email]
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

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

jtuchel

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

Thomas,

thanks for your interest. Yes, I was sure I am not alone in my search for best practices and recipes. Or stories of failures to learn from.

So we are already 3, because I got a PM from another developer not really located in our Region ;-)

Hope to hear from a few more soon.

Am 28.09.17 um 10:53 schrieb Thomas Brodt:

Hi all

I would be very interested in a group sharing any experience with Glorp.

We currently have exactly these questions on our list that Joachim mentions, and some more. And as we also have an Object Lens Visualworks application, there are interesting questions regarding similarities and differences between the two, in their usage and their internals. And besides the rather introductory documentation for basic operations and mapppings, there is none of the more "advanced" techniques and best practices that come with a larger business application if you succeeded with the first steps.

We're located near the border of Switzerland to Germany, so the region would match ;-)

But anyone interested whereever in the world should take this opportunity to get in touch!

Thomas

Am 28.09.2017 um 08:56 schrieb [hidden email]:
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                         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

-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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

Esteban A. Maringolo

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

In reply to this post by jtuchel

2017-09-28 3:56 GMT-03:00 [hidden email] <[hidden email]>:
> Hi there,

> 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.

For that purpose, and in the context of Magritte, I created a
MAEventedMemento, which basically redefines default #commit, and is
evented in a three phase commit: as in #aboutToCommit, #commit,
#postCommit, then in my magritte based editors I hook into these
events as:

onAboutToCommit: anObject
self app databaseSession hasUnitOfWork ifFalse: [ self app beginUnitOfWork ].
self app register: anObject

I use these in the context of a nested tree of objects where you can
"dive in" to edit references, or add elements to a collection.

It is not recommended to keep transactions open for a long time
because you have to handle the locking and other side-effects of doing
it, but in my use case it was simpler to handle that than to implement
a whole object graph buffering.

> 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

I never had that behavior, since the Glorp session was tied to a
Seaside session, and the Seaside session ended at some point. I'm
talking about months of uptime with a small set of Pharo images
handling the app.

The alternative is to use different types of caching policy in your
Glorp session, but at that time Pharo's support of Ephemerons and
other weak references wasn't clear, so I decided to not explore that
path.

I know you use VAST, I'm sure its support for different caching
policies is better.

> 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.

As it said in the Buddhist temple: "A hundred monks, a hundred religions"

> 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.

I'm not actively using Glorp lately (only marginally in one project),
but I'm fond to ORMs,
I coded a complete ORM for my previous company (still being used) and
I like SQL.

> 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.

That's a little far from where I regularly am, but as I told you
before, I'll be in Europe during November, and I'm willing to travel
for one or two days to Switzerland.

> The second best is probably some sort of online conference call. Maybe even
> on a regular basis.

I could certainly attend to these more often. :)

Regards!

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Tom Robinson

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

In reply to this post by jtuchel

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, [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 mailto:[hidden email]
>> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
> _______________________________________________
> Esug-list mailing list
> [hidden email]
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Madhu

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

In reply to this post by jtuchel

I would be interested as well. I live in central Switzerland, coming near the northern Swiss border wouldn't be a problem.

Regards,
Madhu.

On 28.09.17 10:56, [hidden email] wrote:

Thomas,

thanks for your interest. Yes, I was sure I am not alone in my search for best practices and recipes. Or stories of failures to learn from.

So we are already 3, because I got a PM from another developer not really located in our Region ;-)

Hope to hear from a few more soon.

Am 28.09.17 um 10:53 schrieb Thomas Brodt:
Hi all

I would be very interested in a group sharing any experience with Glorp.

We currently have exactly these questions on our list that Joachim mentions, and some more. And as we also have an Object Lens Visualworks application, there are interesting questions regarding similarities and differences between the two, in their usage and their internals. And besides the rather introductory documentation for basic operations and mapppings, there is none of the more "advanced" techniques and best practices that come with a larger business application if you succeeded with the first steps.

We're located near the border of Switzerland to Germany, so the region would match ;-)

But anyone interested whereever in the world should take this opportunity to get in touch!

Thomas

Am 28.09.2017 um 08:56 schrieb [hidden email]:
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                         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
-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          [hidden email]
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
--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Esteban A. Maringolo

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

Any further plans on this?

I'm trying to arrange my schedule for the next month, and I'd love to
make a stop to discuss about this and also put some faces on the names
:)

Regards!

Esteban A. Maringolo

2017-10-02 4:29 GMT-03:00 Madhu <[hidden email]>:

> I would be interested as well. I live in central Switzerland, coming near
> the northern Swiss border wouldn't be a problem.
>
> Regards,
> Madhu.
>
>
> On 28.09.17 10:56, [hidden email] wrote:
>
> Thomas,
>
> thanks for your interest. Yes, I was sure I am not alone in my search for
> best practices and recipes. Or stories of failures to learn from.
>
> So we are already 3, because I got a PM from another developer not really
> located in our Region ;-)
>
> Hope to hear from a few more soon.
>
>
>
>
> Am 28.09.17 um 10:53 schrieb Thomas Brodt:
>
> Hi all
>
> I would be very interested in a group sharing any experience with Glorp.
>
> We currently have exactly these questions on our list that Joachim mentions,
> and some more. And as we also have an Object Lens Visualworks application,
> there are interesting questions regarding similarities and differences
> between the two, in their usage and their internals. And besides the rather
> introductory documentation for basic operations and mapppings, there is none
> of the more "advanced" techniques and best practices that come with a larger
> business application if you succeeded with the first steps.
>
> We're located near the border of Switzerland to Germany, so the region would
> match ;-)
>
> But anyone interested whereever in the world should take this opportunity to
> get in touch!
>
> Thomas
>
>
> Am 28.09.2017 um 08:56 schrieb [hidden email]:
>
> 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:[hidden email]
> 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
>
>
>
> --
> -----------------------------------------------------------------------
> Objektfabrik Joachim Tuchel mailto:[hidden email]
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "glorp-group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/glorp-group.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "glorp-group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/glorp-group.
> For more options, visit https://groups.google.com/d/optout.

jtuchel

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

In reply to this post by Tom Robinson

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:[hidden email]
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

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

Esteban A. Maringolo

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

2017-10-10 11:08 GMT-03:00 [hidden email] <[hidden email]>:

> 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.

If obj isn't complex (as in without many relations), then you're safe
doing a refresh.

But you should be aware that was #refresh: does is to perform a Query
without checking the cache first (and updating it afterwards). It is,
it sets true the #shouldRefresh property of the query.

I explicitly setup manually my queries with shouldRefresh as true for
certain classes (e.g. Invoice, PurchaseOrder, etc.). So I'm sure I
always get the latest version committed from the database, and also
the referenced objects (Customer, etc.).

Regards,

Esteban A. Maringolo

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

jtuchel

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

Esteban,

we try to avoid refreshing and only refresh objects manually to affect performance as little as possible. It works for now and we'll see how far we get with this.

The main conecrn in my posting, however, was whether it is safe to work on objects that were read before a commitUnitOfWork and do consecutive commits again and maybe several times again. As I said, we first tried to use commit...AndContinue to make sure the objects are still being managed correctly by Glorp after a commit. But it seems that is not necessary, even if you do not refresh the objects... The fact that this seems to work leaves a bitter taste on my tongue. Feels a bit like seeking shelter behind a few straws from an approaching avalanche ;-)

Joachim

Am Mittwoch, 11. Oktober 2017 18:38:44 UTC+2 schrieb Esteban A. Maringolo:

2017-10-10 11:08 GMT-03:00 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="AGuasRRIAAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jtu...@... <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="AGuasRRIAAAJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">jtu...@...>:

> 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.

If obj isn't complex (as in without many relations), then you're safe
doing a refresh.

But you should be aware that was #refresh: does is to perform a Query
without checking the cache first (and updating it afterwards). It is,
it sets true the #shouldRefresh property of the query.

I explicitly setup manually my queries with shouldRefresh as true for
certain classes (e.g. Invoice, PurchaseOrder, etc.). So I'm sure I
always get the latest version committed from the database, and also
the referenced objects (Customer, etc.).

Regards,

Esteban A. Maringolo