Google Android - это несложно

Доброго времени суток.
Есть таблица в которой пытаюсь получить строки по трем полям:
[syntax=java]String selectionTool = (PLASMA_THICKNES + "=? AND " + STEEL_GRADE + "=? AND " + LEVEL_TOOL + "=?");
String[] selectionArgsTool = new String[]{itemthicSteelV, "'" + itemmSteelV + "'", itemclassToolV};
CursorLoader(getActivity(), TOOL_URI, null, selectionTool, selectionArgsTool, null);[/syntax]
Падает контент провайдер, лог:
06-01 16:11:34.238: E/DatabaseUtils(680): Writing exception to parcel
06-01 16:11:34.238: E/DatabaseUtils(680): java.lang.IllegalArgumentException: the bind value at index 3 is null
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteProgram.bindString(SQLiteProgram.java:164)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteProgram.bindAllArgsAsStrings(SQLiteProgram.java:200)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:47)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:1314)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteDatabase.queryWithFactory(SQLiteDatabase.java:1161)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1032)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.database.sqlite.SQLiteDatabase.query(SQLiteDatabase.java:1200)
06-01 16:11:34.238: E/DatabaseUtils(680): at ru.htsprovider.htspcontentprovider.HTSProvider.query(HTSProvider.java:241)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.content.ContentProvider.query(ContentProvider.java:652)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.content.ContentProvider$Transport.query(ContentProvider.java:189)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:113)
06-01 16:11:34.238: E/DatabaseUtils(680): at android.os.Binder.execTransact(Binder.java:367)
06-01 16:11:34.238: E/DatabaseUtils(680): at dalvik.system.NativeStart.run(Native Method)
[syntax=java]case URI_PLASMA:
if (TextUtils.isEmpty(sortOrder)){
sortOrder = FILE_NAME_PLASMA + " ASC";
}
db = dbHelper.getReadableDatabase();
241 cursor = db.query(DATA_TOOL_PLASMA, projection, selection,
selectionArgs, null, null, sortOrder);
break;[/syntax]
В чем может быть дело?

the bind value - это параметры, с крытые под ?. Их у тебя три. С третьим что-то не так - он нулл.
нулл нельзя использовать в запросах - можно только пустые строки "" использовать. А когда нулл то пишется в запросах IS NULL

В общем не получается через вопросы(((
Сделал так:
[syntax=java] new CursorLoader(getActivity(), TOOL_URI, null, PLASMA_THICKNES + "=" + itemthicSteelV + " and " + STEEL_GRADE + "='" + itemmSteelV + "' and " + LEVEL_TOOL + "=" + itemclassToolV, null, null);[/syntax]

плохо. Надо через вопросы.

ну и зачем тут провайдер то? почему нельзя просто написать SELECT FROM?

altwin писал(а):ну и зачем тут провайдер то? почему нельзя просто написать SELECT FROM?

а причем тут вообще провайдер? речь не о нем.

Foenix писал(а):

altwin писал(а):ну и зачем тут провайдер то? почему нельзя просто написать SELECT FROM?

а причем тут вообще провайдер? речь не о нем.

Дело именно в том, что ваши провайдеры и курсоры дают дополнительный слой, который в данном конкретном случае мешает поиску ошибки и отладки. Написав простой sql запрос не только уменьшатся ресурсные затраты и увеличится скорость, но и ошибка станет очевидной. Зачем громоздить все это если обычнми проверенными запросами к базе все эти задачи решаются в считанные минуты?

altwin писал(а):

Foenix писал(а):

altwin писал(а):ну и зачем тут провайдер то? почему нельзя просто написать SELECT FROM?

а причем тут вообще провайдер? речь не о нем.

Дело именно в том, что ваши провайдеры и курсоры дают дополнительный слой, который в данном конкретном случае мешает поиску ошибки и отладки. Написав простой sql запрос не только уменьшатся ресурсные затраты и увеличится скорость, но и ошибка станет очевидной. Зачем громоздить все это если обычнми проверенными запросами к базе все эти задачи решаются в считанные минуты?

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

Отладку , кстати, делать там легко и просто. Я сама за полные запросы, но в данном случае, гугл уверяет. что такого вида запросы делать людям не знающим что такое sql - проще. Например, если юзать построитель запросов (что они рекомендуют для к.п.) - то там есть простая функция SQL - которая выдает готовенький стоковый запрос , как говорится для выводов в лог и для проверки.
Кроме того, если запросы простые, как тут, то иногда пострители удобнее, т.к. позволяют по-быстрому универсальные запросы создавать.
У меня вначале было очень много запросов. В результате перехода на построители - остались только самые сложные , я их через rawSQL запускаю или execSQL или как его там. А все простые проходят через одну ветку в соответсвюущих switch в контент-провайдере, т.к. универсальные.

Это же sqlite... что тут еще упрощать то. SQL всегда был и будет эффективен, а любая абстракция вокруг -лишняя головная боль и в любом случае, как бы хорошо google ее не отлаживал, это дополнительный слой и дополнительные затраты. А о новичках тем более странно, нафига им забивать голову этими гугловскими приколами, если любому программисту всеравно придется учить sql. А пытаться сделать это после того как всякого рода недоделанные ORM уже забиты на уровне рефлексов -это как наполнить стакан, который уже не пустой... Я уже не говорю о том, что мы насилуем свой мозг изучая всю эту чушь и для чего? Чтобы в конце концов проект вырос и единственным способом оптимизации был отказ от ORM провайдеров и подобной ереси и оптимизации работы с бд именно хардкором... неужели нельзя сразу делать правильно? Именно правильно, ведь в итоге любой уважающий себя проект переписывают на raw sql

Артем, ты слишком приземленного мнения об alexmx. Поверь мне, он уже понял мое сообщение "плохо" и сделает все необходимое)) он уже понял что именно. Я его хорошо знаю.

Контент-провайдер и курсор-лоадер не являются "абстракцией" и лишней надстройкой надо sqlite, как orm. ОРМ _ это вообще, вообще не то!
И мне стыдно-стыдно-стыдно такое читать от тебя.
Поверь мне , в данной теме твое сообщение звучит как ересь) ее не поймут и не поверят))
Проповедуй что-нибудь другое

Так разобрался пока вы тут споры спорите
В общем у меня не получалось с вопросами потому что я экранировал значение одной переменной:
[syntax=java]"'" + переменная + "'"[/syntax]
Делал это для того что там есть и цифры и буквы (к примеру 09G2S)
Сейчас переписал вот так:
[syntax=java]String selectionTool = (PLASMA_THICKNES + "=?" + " and " + STEEL_GRADE + "=?" + " and " + LEVEL_TOOL + "=?");
String[] selectionArgsTool = new String[]{itemthicSteelV, itemmSteelV, itemclassToolV};[/syntax]
Запрос:
[syntax=java]cursorLoader = new CursorLoader(getActivity(), TOOL_URI, null, selectionTool, selectionArgsTool, null);[/syntax]
И все собственно заработало
Вывод: при таком методе не использовать экран

Это же sqlite... что тут еще упрощать то. SQL всегда был и будет эффективен, а любая абстракция вокруг -лишняя головная боль и в любом случае, как бы хорошо google ее не отлаживал, это дополнительный слой и дополнительные затраты. А о новичках тем более странно, нафига им забивать голову этими гугловскими приколами, если любому программисту всеравно придется учить sql. А пытаться сделать это после того как всякого рода недоделанные ORM уже забиты на уровне рефлексов -это как наполнить стакан, который уже не пустой... Я уже не говорю о том, что мы насилуем свой мозг изучая всю эту чушь и для чего? Чтобы в конце концов проект вырос и единственным способом оптимизации был отказ от ORM провайдеров и подобной ереси и оптимизации работы с бд именно хардкором... неужели нельзя сразу делать правильно? Именно правильно, ведь в итоге любой уважающий себя проект переписывают на raw sql

Да sql учить необходимо в любом случае)))

Поверь мне, он уже понял мое сообщение "плохо"

Конечно понял, это "РЕМЕНЬ!!!"

не поняла что ты сделал с переменной экра-что?
но это что-то плохое, явно.

Я в каком то запросе не мог из поля выдернуть строку "10.584.584" потому что sqlite пытался привести к числовому типу, вот я и лепил одинарные кавычки, а тут по аналогии их вставлял.

От этих проблем избавляют параметры в запросе. Ну и еще от более серьезных.

От каких?

Foenix писал(а):Артем, ты слишком приземленного мнения об alexmx. Поверь мне, он уже понял мое сообщение "плохо" и сделает все необходимое)) он уже понял что именно. Я его хорошо знаю.

Контент-провайдер и курсор-лоадер не являются "абстракцией" и лишней надстройкой надо sqlite, как orm. ОРМ _ это вообще, вообще не то!
И мне стыдно-стыдно-стыдно такое читать от тебя.
Поверь мне , в данной теме твое сообщение звучит как ересь) ее не поймут и не поверят))
Проповедуй что-нибудь другое

Собственно тут все просто, ORM я называю не конкретную библиотеку в спеке которой написанно, что она ORM для чего -то, а саму по себе абстракцию использования объектной модели для описания реляционных связей, именно потому я контент провайдеры ваши, курсоры(которые тоже являются банальной абтсракцией не более и не менее) и т.д. объединяю упрощенным для меня термином ORM. Учитывая, что это java и все является объектом, абсолютно любая библиотека(не важно добавленна ли она в стандартную поставку любимым вами гуглом) для работы с бд является объектной абстракцией к бд, т.е. ORM.
P.S. вообще наверно просто скучно стало или поговорить не с кем в конкретный момент, на самом деле я не такой на самом деле мне пофигу и я просто пальцы размять решил наверно ///