Maybe we know one thing or the other about this :) There are pros and cons to both approaches. Nothing was dismissed. For global, table-level indexes we need some of distributed commit protocol. For "index transactions" it is slightly simpler, because they are known ahead of time to be idempotent; maybe we can up with something less strict than 2pc/paxos.
Naively updating another table and say "now we have secondary indexes" *is* going to bring unexpected surprises, as it will work until it breaks because of concurrency issues. If you want that, write to two tables from your client. I think this is a good discussion. -- Lars ________________________________ From: Michael Segel <[email protected]> To: [email protected] Cc: "[email protected] Purtell" <[email protected]>; lars hofhansl <[email protected]> Sent: Tuesday, August 14, 2012 8:01 PM Subject: Re: Secondary indexes suggestions Perhaps not dismissive but more focused on indexing at the region. And it wasn't just you, but also Lars. Also don't read in to what I am saying as an argument. Its not. ;-P I think the issue is how to approach the problem. On Aug 14, 2012, at 9:49 PM, Andrew Purtell <[email protected]> wrote: > On Tue, Aug 14, 2012 at 7:38 PM, Michael Segel > <[email protected]> wrote: >> I think you need to think outside of the box... >> But I think you've been too dismissive of looking at the index at the table >> level and not at the region level. > > I'd be interested if you can point out exactly where I dismissed > something, as in "this is not a good idea..." or "this is wrong..." or > any other explicit statement. Otherwise, you are reading in something > as implicit that isn't there. I contributed a few thoughts on the > subject as opposed to writing a treatise. Why does this have to be an > argument instead of a discussion? > > But if you don't mind I'm not going to look at this thread further. > > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet > Hein (via Tom White) >
