Open Stack

Hi all,

Dima, I think I understand your reasoning but I have some issues with that.
I agree that binary logic is much more straightforward and easy to
understand and use. But following that logic, having the only one hardcoded
consistency level is even easier and more understandable.
As I can see, the idea of the proposal is to provide user a more
fine-grained control on consistency to leverage backend features AND at the
same time to not bound ourselves with only this concrete backend's
features. In scope of Maksym's proposal choice between WEAK/QUORUM for me
is pretty much the same as your FALSE/TRUE. But I'd prefer to have more.

PS Eager to see your new index design


On Tue, Apr 29, 2014 at 7:44 AM, Dmitriy Ukhlov <dukhlov at mirantis.com>wrote:

>
> Hello Maksym,
>
> Thank you for your work!
>
> I suggest you to consider more general approach and hide backend specific
> staff. I have the next proposal:
> 1) add support for inconsistent write operation by adding PutItem,
> UpdateItem and DeleteItem request parameters "consistent" = True of False
> (as well as GetItem and Query requests)
> 2) add possibility to set backend specific metadata (it would be nice to
> use some generic format like json) per table in scope of create table
> request. I suggest to specify mapping for Cassandra consistency level per
> operation type (consistent read, inconsistent read, consistent write,
> inconsistent write)
>
> I agree that now we have a limitation for inconsistent write operation on
> tables with indexed fields and for requests with specified expected
> conditions. I have thought about how to overcome this limitation and it
> seems that I found out solution for index handling without CAS operation.
> And maybe it is reasonable to redesign it a bit.
>
> On Mon, Apr 28, 2014 at 8:33 AM, MAKSYM IARMAK (CS) <
> Maksym_Iarmak at symantec.com> wrote:
>
>>  Hi,
>>
>> Because of we can't use inconsistent write if we use indexed table and
>> condition operations which indexes based on (this staff requires the state
>> of data), we have one more issue.
>>
>> If we want to make write with consistency level ONE (WEAK) to the indexed
>> table, we will have 2 variants:
>> 1. Carry out the operation successfully and implicitly make write to the
>> indexed table with minimally possible consistency level for it (QUORUM);
>> 2. Raise an exception, that we can not perform this operation and list
>> all possible CLs for this operation.
>>
>> I personally prefer the 2nd variant. So, does anybody have some
>> objections or maybe another ideas?
>>
>>  ------------------------------
>> *From:* MAKSYM IARMAK (CS) [Maksym_Iarmak at symantec.com]
>> *Sent:* Friday, April 25, 2014 9:14 PM
>> *To:* openstack-dev at lists.openstack.org
>> *Subject:* [openstack-dev] [MagnetoDB] Configuring consistency draft of
>> concept
>>
>>   >So, here is specification draft of concept.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Dmitriy Ukhlov
> Mirantis Inc.
>



-- 

Best regards,

Illia Khudoshyn,
Software Engineer, Mirantis, Inc.



38, Lenina ave. Kharkov, Ukraine

www.mirantis.com <http://www.mirantis.ru/>

www.mirantis.ru



Skype: gluke_work

ikhudoshyn at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140429/9b8612b7/attachment.html>