Glorp duplicate objects problem
Locked
 
|
Hello everyone,
I'm having a problem where rogue copies of objects keep appearing in memory . This is on the Pharo 1.3 one click image plus a few extra prerequisites including Seaside 3. The glorp test suite works fine. To save a new object I am using - session transact: [glorpSession register: anObject] . To update an existing object I am using - glorpSession modify: anObject in: [aBlock value] There are a number of classes that have collections of other classes. When an instance x of class X has a collection of Ys, I do a glorpsession refresh of x after saving a new Y, in so that x knows about the new y that should appear in its collection. When, after constructing a few objects, I inspect aClass allInstances, every so often duplicate instances appear. They have all the same instance data but self hash gives a different answer. This duplication behaviour is not consistent. Sometimes no duplicates get created, sometimes 1, sometimes 2 etc. There is no problem with duplicate data in the database tables, just in memory. I have a unit test which checks the value of an attribute and this is failing because the attribute contains a duplicate copy of the original instance and comparison therefore fails. It would take some time to set up a simpler test scenario to illustrate, but for now I wonder if this description rings any bells for anyone? Does this sound like anything any of you have encountered before? Regards, thanks Nick Davis |
Re: Glorp duplicate objects problem
|
|
I don't think that's anything to worry about. The way that Glorp's unit of work works is that it makes shallow copies of the objects so it can compare their state at the end to see what's changed. That's probably where you're seeing the extra instances from. If you have a test that's doing an allInstances in order to check behaviour then, well, first of all, don't do that. But if you really want to, at least in VisualWorks, doing a full garbage collect first will get rid of any lingering instances, because allInstances can find things that are not referenced but not yet collected. If you're seeing a different instance without doing an allInstances, then that seems like something's wrong. I'd check to make sure that one of the two isn't actually a proxy, which could cause == to fail. Other than that, I can't think of anything. On 14 February 2013 02:17, nickdavis <[hidden email]> wrote: Hello everyone, 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Hello Alan,
Thanks a lot for the helpful reply. :) I see what you mean about behind the scenes temporary extra instances, and won't worry about those. This problem was indeed caused by a Proxy object. I am relatively new to Smalltalk and didn't know about Proxy objects until now. The call to glorpSession refresh is changing an attribute's class to be Proxy, which later causes == to fail. Our situation is Orders and Items. An Item has an attribute Order which identifies which Order it belongs to. An Order has a collection of Items. When I add a new Item and save that by registering with glorp, the parent Order doesn't know of this new Item, and this item is missing from the collection, until either : (a) I refresh the Order, which undesirably leads to other attribute(s) of Order becoming Proxy , or (b) I simply add the Item to the Order in memory to keep it in line with the DB, but I suspect this is causing problems later when trying to delete. I wonder if you have some recommended best practice to avoid such problems? Regards, Nick -- 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Re: Glorp duplicate objects problem
|
Hi Nick,
If the object you delete is contained within some or multiple collections you should probably need to refresh those collections in order for them to know you object is no longer there.
Regards, @+Maarten,
On Monday, 18 February, 2013 18:06, "nickd" <[hidden email]> said: Hello Alan, 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Hi Maarten,
Thanks for replying. Indeed one needs to do this but what about when tearing down test fixtures? Lets say you have an Order test fixture with some items. In the tear down you must delete the items first before the Order. So you delete the Items, then refresh the Order, then immediately delete the Order. This feels a bit wrong but maybe that's what's needed with glorp? I will try to do that for now and see what happens. I must say - in general the docs for how to do the mapping, make a descriptor system etc and basic save and read are very good (the Whitney tutorial, although old, covers that well) but I have found when learning glorp that understanding how/when to do updates, and when to do refresh etc, was a bit less obvious to me / harder to get information on. Regards, Nick On Monday, 18 February 2013 17:37:21 UTC, [hidden email] wrote: -- 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
Re: Glorp duplicate objects problem
|
|
The expectation is that if you have bi-directional relationships in memory, when you modify them in memory you'll keep them consistent there. So if you add a new item, you should also add it to the order's collection. I'm not sure why you say that this would cause problems with deleting. For a test fixture, the order of deletes doesn't matter. Or, more correctly, it does matter, but Glorp will do them in the right order for you. So if you do the operations in a single unit of work, Glorp will figure out the appropriate delete order, as long as you've told it what the foreign keys are.
What most of the Glorp tests do is simpler, though. Start a transaction, write the objects you need to do the test, do whatever the test has to do, verify it, then roll back the transaction. That way you're guaranteed that the database gets back to the correct state, no matter how badly any test fails. As long as you're not testing transations working, that works pretty well.
On 19 February 2013 05:12, nickd <[hidden email]> wrote: Hi Maarten, 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Hi Alan,
Thanks for the reply which clarified things greatly and led to a solution. :) I'm now keeping the data consistent in memory instead of leaving glorp to do the work with a glorpSession refresh (which was causing the proxy problem). The problem I was having with delete turned out to be caused by doing a separate transaction for each object delete! Doh! I had got muddled up about which methods out of transact: , inUnitOfWorkDo: and inTransactionDo would start a new transaction and which wouldn't. Anyway, now I've made sure there's just a single unitOfWork around the whole lot it works. Phew! Thanks again for your help and its been an interesting experience learning how this works. To me its taken a bit of getting used to the idea of having a block of changes that lives inside a UnitOfWork, rather than the more traditional model of change your data in memory then open a transaction and commit it. That might be because I'm a bit slow, or, it could be something that a bit more documentation would stop other people getting confused by perhaps. Thanks again for Glorp. Its a pleasure to work with. Regards, Nick -- 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 http://groups.google.com/group/glorp-group?hl=en. For more options, visit https://groups.google.com/groups/opt_out. |
«
Return to GLORP
|
1 view|%1 views
| Free forum by Nabble | Edit this page |