Multiple async requests. IN() is a performance nightmare unless you're
querying against a single partition key.
On Fri, Jun 12, 2015 at 1:09 PM Sotirios Delimanolis <sotodel...@yahoo.com>
wrote:
> Similarly, should we send multiple SELECT requests or a single one with a
> SELECT...IN ?
>
>
>
> On Wednesday, June 10, 2015 11:27 AM, Sotirios Delimanolis <
> sotodel...@yahoo.com> wrote:
>
>
> Will this "eventually they will all go through" behavior apply to the IN?
> How is this query written to the commitlog?
>
> Do you mean prepare a query like
>
> DELETE FROM MastersOfTheUniverse WHERE mastersID = ?;
>
> and execute it asynchronously 3000 times or add 3000 of these DELETE (bound)
> prepared statements to a BATCH statement executed asynchronously?
>
>
>
>
>
>
> On Wednesday, June 10, 2015 9:51 AM, Jonathan Haddad <j...@jonhaddad.com>
> wrote:
>
>
> Batches don't work like that. It's possible for some to succeed, and
> later, the rest will. Atomic is the incorrect word to use, it's more like
> "eventually they will all go through".
>
> Do not use IN(), use a whole bunch of prepared statements asynchronously.
>
> On Wed, Jun 10, 2015 at 9:26 AM Sotirios Delimanolis <sotodel...@yahoo.com>
> wrote:
>
> Hi,
>
> When executing a DELETE statement with an IN clause, where the list
> contains partition keys, what is the underlying behaviour with regards to
> atomicity?
>
> DELETE FROM MastersOfTheUniverse WHERE mastersID IN ('Man-At-Arms', 'Teela');
>
>
> Is it going to act like an atomic batch where if one fails, all fail? If
> that is the case, is there any reason to use a BATCH statement with
> multiple single DELETE statement or should we always prefer a DELETE with
> an IN clause?
>
> For example, given 3000 keys for rows I want to delete, should I issue a
> single DELETE query and provide all the keys in the IN argument or should
> I add 3000 DELETE queries to a BATCH statement?
>
> Thank you,
> Sotirios
>
>
>
>
>
>
>
