I'm not really set on one approach, I'm with you in thinking that if we keep with the existing pattern, we should trap reinserts and updates of non-existent resources, so I want to do something about it... Either change our current pattern or trap bad operations. I just picked my current approach based on the initial feedback I got when I asked what the preferred direction was in IRC.
On Mon, Aug 17, 2009 at 1:41 AM, Stefan Andersson<[email protected]> wrote: >> I propose that we change to just having one "Store" method that >> replaces both the insert and update method, which will insert or >> update. This is what we have in practice with MySQL, so this will >> just change the interface to match it. My biggest concern would be >> breaking external data providers. > > Since I was the one who painstakingly separated this into two methods, I'm > opposed to merging it, but won't fight it, so a 0 from me. > > But: > > It's a very common separation of context in most data workflows to clearly > separate Create from Update, and from a data integrity standpoint, you do > want to be able to trap re-inserts and updates of non-existent resources, as > these are indications something has gone wrong. > > Although the above might come off as somewhat abstract, fact is that a > majority of data storage architectures enforce and rely on the separation, > forcing you to do an extra lookup before each operation if you throw the > semantics away. I did the separation just because the extra lookup was > causing pain. (Though this was like 1,5 years ago - much has happened since) > >> When I mentioned this idea to Adam, he also mentioned changing the >> naming of the Fetch methods to Get, so that everything will be >> consistent. I have an example of what this change would look like on >> this mantis entry: http://opensimulator.org/mantis/view.php?id=4015 >> Any feedback or thoughts on this idea is greatly appreciated. > > Even better would be introducing the TryGet pattern. > > /Stefan > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
