SQLite вместо update делает update+insert. Это баг или фича?

[Tamachi]

SQLite вместо update делает update+insert. Это баг или фича?

Вот код,который делает update записи в БД.

public Boolean updateBeaconName(long beaconId, String beaconName) {
if (beaconId<0) {
return false;
}
Boolean result = false;
try {
SQLiteDatabase db = getWritableDatabase();
ContentValues contentValues = new ContentValues();
contentValues.put(NAME_COLUMN_NAME, beaconName);
contentValues.put(LOW_CASE_NAME_COLUMN_NAME, beaconName.toLowerCase(Locale.getDefault()));
String where ="("+ID_COLUMN_NAME+"=?)";
Log.d("AAA", String.format("Updating beacon id=%d name to %s", beaconId, beaconName));
int count = db.update(BEACON_TABLE_NAME, contentValues, where, new String[] { String.valueOf(beaconId) });
Log.d("AAA", String.format("%d rows affected", count));
result = ( count > 0 );
db.close();
} catch(Exception e) {
result = false;
}
return result;
}

public Boolean updateBeaconName(String beaconName, Cursor cursor) {
if (cursor==null) {
return false;
}
long beaconId = -1;
try {
beaconId = cursor.getInt(cursor.getColumnIndex(ID_COLUMN_NAME));
} catch (Exception e) {
beaconId = -1;
}
if (beaconId<0) {
return false;
}
return updateBeaconName(beaconId, beaconName);
}

Использую его из списка, созданного при помощии SimpleCursorAdapter


После вызова метода updateBeaconName старая запись не удаляется, а новая создаётся.

Например, если сейчас у меня в БД оидин beacon с именем "AAA".
Вызываю updateBeaconName чтобы переименовать его в "BBB".

Однако после этого вижу в базе не одну, а две записи: первая с именем "AAA", а вторая -- с именем "BBB".

Это что новый баг андроида такой или я чего-то не догоняю?

Вот уже почти полмесяца над этой ерундой бюсь и все не могу понять как в андроиде сделать самый простой update.
Ну, то есть просто изменить запись в БД.

[Foenix]

отформатируй нормаьлно код, читать не возможно. ПОложи сюда сиквелы создания таблиц которые используются, их данные и так далее
Полмесяца - многовато для такой проблемы.

[Tamachi]

Вот как база создаётся:

@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL("create table " + BEACON_TABLE_NAME + " ( " + ID_COLUMN_NAME
+ " integer primary key autoincrement, "
+ NAME_COLUMN_NAME + " text collate nocase, "
+ LOW_CASE_NAME_COLUMN_NAME + " text collate nocase, "
+ IMEI_COLUMN_NAME + " text, "+ PHONE_COLUMN_NAME +" text);");
}

Код отформатировал, но после вставки он теряет форматирование.

[=bor=]

Код отформатировал, но после вставки он теряет форматирование

В панели форматирования есть кнопка Code, нажимайте на неё и вставляйте код между тегов, получится так:

Код: Выделить всё

	@Override
	public void onCreate(SQLiteDatabase db) {
		db.execSQL("create table " + BEACON_TABLE_NAME + " ( " + ID_COLUMN_NAME 
				+ " integer primary key autoincrement, " 
		        + NAME_COLUMN_NAME + " text collate nocase, "
		        + LOW_CASE_NAME_COLUMN_NAME + " text collate nocase, "			
				+ IMEI_COLUMN_NAME + " text, "+ PHONE_COLUMN_NAME +" text);");
	}

[Tamachi]

Набирая этот текст, я не вижу никакой панели форматирования.

[Tamachi]

Кстати, с задачей разобрался. Надо было перед update закрывать не только курсор , но ещё и DBHelper.

[=bor=]

Набирая этот текст, я не вижу никакой панели форматирования.

Ниже поля для ответа есть кнопка "Редактор".

[Foenix]

Кстати, с задачей разобрался. Надо было перед update закрывать не только курсор , но ещё и DBHelper.

да ерунда это все

[Tamachi]

Кстати, с задачей разобрался. Надо было перед update закрывать не только курсор , но ещё и DBHelper.

да ерунда это все

Дык больше всего бесит то, что основной функционал программы уже давно готов. А работать приходится со всякими "мелочами". И вот на эти самые мелочи времени уходит в десятки, нет -- в сотни раз больше, чем на основной функционал. И при этом постоянно натыкаешься на сообщения о том, что та или иная фича "deprecated" -- приходится повторно копаться в том, что уже когда-то делал! Например, Notifications теперь стали пищать про "deprecated" -- приходится отвлекаться от основной канвы разработки и думать как это исправить.... Потом Eclipse IDE потребовал обновления. Обновил --- все перестало компилиться. Опять долго разбирался в причинах. Оказывается новая IDE совсем подругому работает с проектами, которые помечены как "is library". В общем время утекает на борьбу с IDE, на переписываение "deprecated"-модулей, --- на всё что угодно, только не на написание основного функционала!

[rezak90]

и мне ещё вчера говорили что писать под андроид одно удовольствие хД)

[Foenix]

все вышеописанное - от незнания (я не говорю что я умная, еще больше ошибок делаю, но считаю что просто не все знаю и это нормальный рабочий процесс) и непонимания логики создателя.

[Tamachi]

все вышеописанное - от незнания (я не говорю что я умная, еще больше ошибок делаю, но считаю что просто не все знаю и это нормальный рабочий процесс) и непонимания логики создателя.

Дык логика создателя -- она кривая!!!


Например, почему входящие и исходящие SMS перехватываются разными методами?

Почему входящую SMS я могу перехватить с помощью BroadcastReceiver, а исходящую SMS надо ловить с помощью чтения БД контактов? Почему создатель не захотел сделать это однотипно?

Почему для Андроида до сих пор нет шаблонов проектирования? Была бы у Андроида логика -- появились бы и шаблоны проектирования.

Почему вызов функций requestlocationupdates и requestsingleupdate работают так, что первую из них лучше никогда не использовать (хотя именно она рекоммендуется создателем)?

API предлагаемое Гуглом --это скорее не API, а огромный набор "How to do"-записей, слабо связанных друг с другом.

Да, андроид впитал в себя все недостатки Java, но при этом он добавил в и без того кривой язык еще больше неразберихи.

У WinPhone и IPhone тоже непростые API, но там хотя бы есть элемент предсказуемости. У андроида же предсказуемость на нуле. И это с учетом того что я тестирую не в эмуляторе, а на реальных телефонах!

Google периодически исправляет баги, но делает он это странным образом: создает какойнибудь Manager
(CursorManager, LoadManager и пр...). В результате для того чтобы сделать приммитивную с точки зрения обычной логики вещь, необходимо созддать целую сеть Менеджеров, передавая данные из одного к другому, добавить к этому Handler, пропихнуть его в UI....

А недавно выяснилось ещё одно ужасающее обстоятельство: многие операции, например получение текущего местонахождения могут работать неправильно (или в лучшем случае не так как ожидалось) в зависимость от того, откуда они вызываются: из службы, из BroadcastReceiver или из Activity.
И об этом в официальных доках ничего не говорится!

Потом,
некоторые возможности закрываются. Например, в последнем API уже нельзя изнутри службы сделать звонок
(я имею в виду не отобразить Activity звонка, а именно -- сделать сам звонок). И с какой стати об этом нет ни слова в документации?

В общем, сплошные риски, сплошная непредсказуемость!

[rezak90]

все вышеописанное - от незнания (я не говорю что я умная, еще больше ошибок делаю, но считаю что просто не все знаю и это нормальный рабочий процесс) и непонимания логики создателя.

если найду ссылку то кину, на хабре была статья что 80% опрошенных по всему миру разработчиков Андроида хотели бы поменять платформу так как разработка под Андроид эм... цензура дальше

[Foenix]

ладно, сдаюсь! может наоборот, это от того, что вы сильно много знаете, а мне каким-то образом удавалось всего этого избегать по жизни может быть потому что я и не знаю так много и не разбираюсь во многом..

[=bor=]

Потом, некоторые возможности закрываются. Например, в последнем API уже нельзя изнутри службы сделать звонок (я имею в виду не отобразить Activity звонка, а именно -- сделать сам звонок). И с какой стати об этом нет ни слова в документации?

Очень интересно! Откуда инфа? На опыте, или где-то прочли? Если можно, поделитесь ссылкой.

[rezak90]

ладно, сдаюсь! может наоборот, это от того, что вы сильно много знаете, а мне каким-то образом удавалось всего этого избегать по жизни может быть потому что я и не знаю так много и не разбираюсь во многом..

я знаю не больше, просто есть с чем сравнить и результат увы не в пользу Андроида

[Tamachi]

Потом, некоторые возможности закрываются. Например, в последнем API уже нельзя изнутри службы сделать звонок (я имею в виду не отобразить Activity звонка, а именно -- сделать сам звонок). И с какой стати об этом нет ни слова в документации?

Очень интересно! Откуда инфа? На опыте, или где-то прочли? Если можно, поделитесь ссылкой.

Просто сам проверял.
Пробовал код, написанный для версии 2.2 откомпилить для 4.1 и запустить.

Сначала получил кучу ошибок компиляции, потом когда с этим разобрался, выяснилось, что не всё работает.
При этом функционал при тестировании вызывался из Activity (то есть в тестовом режиме), а в реальном приложении то же самое должна была делать служба. Вот тогда-то и выяснилась зловещая правда: не всё, что разрешено Activity разрешено службе. Но мне всё-таки удалось найти компромис: пришлось вызывать часть функционала из BroadcastReceiver и c помощью Intent передавать её в службу. Это значительно замедлило работу программы (теперь ясно, почему тормозят андроиды на 4-ядерных процах!!!), зато все же заявленный функционал был реализован.


Но больше всего меня бесит тот факт, что API android как бы специально провоцирует, чтобы однородные данные хранились в разных файлах. То есть нельзя выделить единый модуль для хранения, скажем информации о таком-то объекте. Волей-неволей из-за упомянутых ограничений придётся часть данных положить в один модуль, часть -- в дургой(например, для того чтобы открыть к ним доступ из службы), а оставшуюся часть -- в ресурсы (например, потому что этого требует setTag()). В результате получается весьма дурно-пахнущий код, в котором потом становится трудно разбираться.

[neoksi]

...
Но больше всего меня бесит тот факт, что API android как бы специально провоцирует, чтобы однородные данные хранились в разных файлах. То есть нельзя выделить единый модуль для хранения, скажем информации о таком-то объекте. Волей-неволей из-за упомянутых ограничений придётся часть данных положить в один модуль, часть -- в дургой(например, для того чтобы открыть к ним доступ из службы), а оставшуюся часть -- в ресурсы (например, потому что этого требует setTag()). В результате получается весьма дурно-пахнущий код, в котором потом становится трудно разбираться.

Готовка приложений под Андроид, сперва более-менее проста, но когда узнаешь все подводные камни особенностей работы разных моделей, то начинаются танцы с бубном и изобретение мега-конструкций. Причем большинство из них, предназначены, чтоб обойти ограничения, которые накладывают отцы-основатели Андрода в поисках оптимизации времени автономной работы устройств.