Size: a a a

2021 January 15

R

R-omk in Tarantool
Eugene Leonovich
а есть какой нить коннектор который умееть батчить?
а твой не умеет?
источник

EL

Eugene Leonovich in Tarantool
я сделал poc, но не могу определился с апи ) хотел посмотреть как у других
источник

R

R-omk in Tarantool
Eugene Leonovich
я сделал poc, но не могу определился с апи ) хотел посмотреть как у других
тебе же для пыхи... там все синхронно я  тебе как то уже предлагал, сделай как в клиенте эластика,  пока кого нибудь из батча не попросят запрос не выполняется,  зато потом выполняется пачкой
источник

EL

Eugene Leonovich in Tarantool
ну я так и сделал
источник

EL

Eugene Leonovich in Tarantool
но тут свои минусы есть
источник

EL

Eugene Leonovich in Tarantool
try {
   $result = $client->call();
} catch (Exception) {}
источник

EL

Eugene Leonovich in Tarantool
в случае отложеного вызова бачта catch не сработает
источник

EL

Eugene Leonovich in Tarantool
нужно держать это в голове либо какой то явный апи для батчинга придумывать
источник

R

R-omk in Tarantool
Eugene Leonovich
в случае отложеного вызова бачта catch не сработает
он должен сработать в момент чтения а не в момент вызова, ведь момент вызова на самом деле не сразу происходит
источник

EL

Eugene Leonovich in Tarantool
try{
 $res1 = $client->call('func2');
 $res2 = $client->call('func1');
} catch (Exception) {
  // не сработает, так как запросы еще не отправились
}

$sum = $res1[0] + $res2[0]; <- exception вне catch
источник

R

R-omk in Tarantool
ну так и есть, а чем проблема то?
источник

EL

Eugene Leonovich in Tarantool
проблема в том, читая код совсем не очевидно что исключение может случится в другом месте и по сути один и тот же код будет иметь разное поведение в зависимости от выбранного режима - синхронный или батчинг
источник

R

R-omk in Tarantool
да нужно назвать подругому и чтобы поведение всегда было по новой схеме
источник

EL

Eugene Leonovich in Tarantool
даже асинхронный режим в этом плане будет лучше и будет вести себя как синхронный, с батчингом можно долго долго искать в чем проблема
источник

EL

Eugene Leonovich in Tarantool
ну вот я и думаю над апи, стоить ли выделять батчинг в отдельный какой-то интерфейс, либо просто описать такие неочевидные моменты в доке )
источник

R

R-omk in Tarantool
еще имей ввиду что в какото момнет появятся интерактивные транзакции,   тогда  появится еще такая сиутация когда ты запросы в одну транзакицю объединяешь




$trx = $client->newTrx();

$res1 = $trx->call('func2');
$res2 = $trx->call('func1');

$trx->commit();



или


$client->newTrx(function($trx){
$res1 = $trx->call('func2');
$res2 = $trx->call('func1');

});
источник

R

R-omk in Tarantool
в последнием случае - функциональщина и неявный комит / ролбэк
источник

EL

Eugene Leonovich in Tarantool
ага, с транзакциями не понятно еще, можно ли их будет пихать в батч или они должны идти одельно - https://github.com/tarantool/queue/issues/124#issuecomment-752069570
источник

R

R-omk in Tarantool
ну скорее всего там каждому запросу  будет просто id  trx  добавлен,  так что  я думаю вполне допустимо в одном батче разные транзакции пихать
источник

EL

Eugene Leonovich in Tarantool
R-omk
еще имей ввиду что в какото момнет появятся интерактивные транзакции,   тогда  появится еще такая сиутация когда ты запросы в одну транзакицю объединяешь




$trx = $client->newTrx();

$res1 = $trx->call('func2');
$res2 = $trx->call('func1');

$trx->commit();



или


$client->newTrx(function($trx){
$res1 = $trx->call('func2');
$res2 = $trx->call('func1');

});
я думал над такой версией и я ее самой первой реализовал, но c таким апи нет возможности слать батчи в разные коннекты. Например у меня есть луп, который асинхронно посылает/читает батчи, и ему не важно, один это коннект или пачка
источник