Направляющие Активная Рекордная находка (: все: закажите =>), проблема
Спасибо @Tobrun за ответ, проблема не в том, что я пропустил accessToken, а в том, что я смешал активность и расположение фрагментов, поэтому компоненты одного из них должны быть в другом. Тем не менее, поиск accessToken заставил меня понять о других возможных.
6 ответов
Я заметил, что в вашем первом примере простой : order => «дата» , запись 7 сортируется перед записью 1 . Этот порядок также показывает, как вы видите результаты в сортировке по нескольким столбцам, независимо от того, сортируете ли вы по посещаемости.
Это, кажется, имело бы смысл для меня, если бы даты не были точно такими же, а дата для 7 предшествовала дате для 1 . Вместо того, чтобы обнаружить, что даты точно совпадают, а затем приступить к сортировке по , сопровождающему , запрос обнаруживает, что даты не равны и просто сортируются по тем же параметрам, что и все другие записи.
Из просмотра я вижу, что SQLite не имеет собственного представления о типах данных DATE или DATETIME и вместо этого предоставляет пользователям выбор чисел с плавающей запятой или текста, который они должны анализировать сами. Возможно ли, что буквальное представление дат в базе данных не точно совпадает? Большинству людей, кажется, нужно использовать функции даты , чтобы даты вели себя так, как вы ожидаете. Возможно, там Это способ обернуть ваш заказ по столбцу с помощью функции даты , которая даст вам что-то конкретное для сравнения, например дата (дата) ASC, посещая DESC . Я не уверен, что синтаксис работает, но это область, на которую нужно обратить внимание для решения вашей проблемы. Надеюсь, это поможет.
не так ли : order => 'column1 ASC, column2 DESC' ?
Обязательно проверьте схему на уровне базы данных напрямую. Раньше я был сожжен этим, когда, например, первоначально была написана миграция для создания столбца: datetime, и я запустил ее локально, а затем настроил миграцию на: date перед фактическим развертыванием. Таким образом, база данных у всех выглядит хорошо, за исключением моей, а ошибки неуловимы.
Я понимаю, почему разработчики Rails пошли с sqlite3 для реализации из коробки, но MySQL так гораздо практичнее, имхо. Я понимаю, что это зависит от того, для чего вы строите свое Rails-приложение, но большинство людей собираются переключить файл database.yml по умолчанию с sqlite3 на MySQL.
Рад, что вы решили свою проблему.
Хорошо, что вы нашли свое решение. Но это интересная проблема. Я испытал это непосредственно непосредственно с sqlite3 (не проходя через рельсы) и не получил тот же самый результат, для меня заказ получился как ожидалось.
Что я предлагаю вам сделать, если вы хотите продолжить копаться в этой проблеме, так это чтобы запустить приложение командной строки sqlite3 и проверить схему и запросы там:
Это покажет вам схему: .schema
А затем просто запустите оператор select, как это было показано в файлах журнала: SELECT * FROM «показывает» ORDER BY по дате ASC, посещая DESC
Таким образом, вы видите, если:
- Схема выглядит так, как вы хотите (эта дата фактически является датой, например)
- Что столбец даты на самом деле содержит дату, а не отметку времени (то есть, у вас нет времени дня, которое портит сортировку)
Проблема в том, что date является зарезервированным ключевым словом sqlite3. У меня была похожая проблема с time, тоже зарезервированным ключевым словом, которое прекрасно работало в PostgreSQL, но не в sqlite3. Решением является переименование столбца.
См. это: Sqlite3 activerecord :order => "time DESC" не сортирует