Wataru, Все так, но часто максимальный размер массива не известен, ну и сразу резервировать большой объем на будущее, это не сосем эффективно, т.к. в точке память может понадобиться кому-то другому.
MARK KURDA, Wataru, Тут есть нюанс. Если используем массив, то при вставке нового элемента есть еще накладные расходы на увеличение длинны массива и это может быть по затрата больше чем все остальное.
Тут наверное (если нужна сортировка только по Ypos, а другие атрибуты могут идти вразнобой) можно использовать что-то вроде hashmap, где key это Ypos, а value сам объект со всеми атрибутами.
По идее, если есть много объектов с повторяющимися Ypos, то сортировать список Ypos будет выгоднее (он будет сильно короче чем список всех объектов) чем гонять строки в большом массиве всех объектов. И так как hasmmap внутри содержит связанный список (в Java), то при добавлении объекта с уже имеющимся Ypos не нужно будет двигать элементы по массиву.
ut1ka, смотрите инструкции try и except.
В общем виде как-то так:
try:
# тут выполняем запрос на добавление нового тэга
curs.execute(sql)
except (MySQLdb.Error) as e:
print(e)
# тут обрабатываем ситуацию, когда sql error
nikitus223, у вас есть три переменные:
int math;
int history;
int geometry;
Положите их сумму в переменную 'a' из моего примера.
Тогда в переменной 'c' будет количество часов, а в переменной 'd' количество минут.
В ответ нужно вывести не одну строку как у вас, а две.
Андрей Андреев, не совсем.
Добавление записи нужно делать отдельным вызовом.
cursor.execute("INSERT users (id, cash) VALUES (1, 0)")
И в запросе я привел пример запроса по добавлению записи в таблицу users, вам видимо нужно не только поля id и cash заполнять при добавлении нового user-а но и все остальные.
Причина в том, что вы всегда делаете
UPDATE users SET cash = cash + 40 WHERE login = ?
А он сработает, только если запись с нужным login ранее была добавлена.
Первым шагом нужно сделать:
INSERT INTO users (login, cash) VALUES ('someone', something)
Примерно похожий вариант использовали, только чтобы не шаманить с офсетами, на случай краша агрегирующего сервиса, все что прилетело в условный Map> сохранял в БД, т.е. был локальный кеш и БД, и коммитили офсет после сохранения в БД. Накладные расходы от БД у нас 20 мс на каждое сообщение, это было приемлемым временем, если это не так, то БД лучше не использовать.
Если агрегирующий сервис падал, то после подъема сервиса он начинал вычитывать кафку и смотреть локальный кеш по order_id и если там пусто, то подтягивал из БД данные по всем незавершенным задачам, если они были.
Рауф, считанную методом nextLine() строку превратить в массив методом split(), а далее проверить есть ли подстрока(слово) done в элементах этого массива и если есть, то прервать цикл ввода. А полученные элементы массив идущие до слова done добавить в ваш список.