Re: MV Keys
Date: Tue, 7 Mar 2006 09:22:04 +0200
Message-ID: <dujcav$qg2$1_at_emma.aioe.org>
"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
news:440cc41e$0$11063$e4fe514c_at_news.xs4all.nl...
> x wrote:
> > mAsterdam wrote:
> >
> >>Marshall Spight wrote:
> >>
> >>>mAsterdam wrote:
> >>>
> >>>>Aside (the example surely illustrates your point)
> >>>>could this removeAt operation possibly be useful
> >>>>in a concurrent environment?
> >>>
> >>>For sure.
> >>
> >>I don't (yet? :-) see how it can be useful etc. by itself.
> >>A little namechange to emphasize the multi-somethingness:
> >>
> >>OurSharedList.removeAt(index) has more serious
> >>sharing problems than, say:
> >>OurSharedList.removeItem(item)
> >>
> >>ISTM the index loses its meaning when I'm not
> >>in sole control of the list.
> >
> >
> >>Hmm... OurSharedList.insertafter(hopefullyexisting item, new item)
> >
> >
> > (insert into OurSharedList(Existing, New)
> > select hopefullyexisting item as Existing, new item as New
> > from OurSharedList
> > where Existing=hopefullyexisting item
> > union
> > select new item as Existing, New
> > from OurSharedList
> > where Existing=hopefullyexisting item) ,
> > (delete from OurSharedList where Existing=hopefullyexisting item)
>
> I wonder if I understand why you delete the (hopefully) existing
> item from OurSharedList (and insert it back in when it was there
> originally). Guess: No simpler way to establish wether it's there and
> have the query fail when it's not?
Have you noticed the comma ?
It stands for multiple simultaneous assignments.
I deleted the old links and added the new ones.
Received on Tue Mar 07 2006 - 08:22:04 CET