Как получить список записей, которые являются частью другой записи в сетевом ответе, после успешного проектирования схемы базы данных комнаты - PullRequest
0 голосов
/ 27 мая 2020

Чего я пытаюсь достичь. * { "cod":"200", "message":0, "cnt":40, "list":[ { "dt":1590602400, "main":{ "temp":306.2, "feels_like":306.4, "temp_min":306.07, "temp_max":306.2, "pressure":1006, "sea_level":1004, "grnd_level":950, "humidity":41, "temp_kf":0.13 }, "weather":[ { "id":802, "main":"Clouds", "description":"scattered clouds", "icon":"03n" } ], "clouds":{ "all":48 }, "wind":{ "speed":3.72, "deg":183 }, "sys":{ "pod":"n" }, "dt_txt":"2020-05-27 18:00:00" }, { "dt":1590613200, "main":{ "temp":305.05, "feels_like":303.65, "temp_min":304.7, "temp_max":305.05, "pressure":1004, "sea_level":1003, "grnd_level":949, "humidity":38, "temp_kf":0.35 }, "weather":[ { "id":803, "main":"Clouds", "description":"broken clouds", "icon":"04n" } ], "clouds":{ "all":68 }, "wind":{ "speed":4.72, "deg":197 }, "sys":{ "pod":"n" }, "dt_txt":"2020-05-27 21:00:00" }, { "dt":1590624000, "main":{ "temp":302.97, "feels_like":304.29, "temp_min":302.74, "temp_max":302.97, "pressure":1004, "sea_level":1004, "grnd_level":949, "humidity":46, "temp_kf":0.23 }, "weather":[ { "id":802, "main":"Clouds", "description":"scattered clouds", "icon":"03n" } ], "clouds":{ "all":47 }, "wind":{ "speed":1.48, "deg":196 }, "sys":{ "pod":"n" }, "dt_txt":"2020-05-28 00:00:00" } ], "city":{ "id":1269843, "name":"Hyderabad", "coord":{ "lat":17.3753, "lon":78.4744 }, "country":"IN", "population":3597816, "timezone":19800, "sunrise":1590538296, "sunset":1590585318 } } на основе ответа json у меня есть следующие классы данных для схемы комнаты Record.class @Entity(tableName = "Record") data class Record( @PrimaryKey(autoGenerate = true) val rid:Long, @SerializedName("dt_txt") val dtTxt: String, @Embedded(prefix = "main_") val main: Main, @Embedded(prefix = "rain_") val rain: Rain, @Embedded(prefix = "wind_") val wind: Wind ) Weather.class @Entity( tableName = "weather", foreignKeys = [ ForeignKey( entity = Record::class, parentColumns = ["rid"], childColumns = ["wid"], onDelete = CASCADE ) ]) data class Weather( @PrimaryKey(autoGenerate = true) val wid:Long, val description: String, val icon: String, val id: Int, val main: String ) WeatherRecord.class class WeatherRecord ( @Embedded val record: Record, @Relation(parentColumn = "rid", entityColumn = "wid") val weather:List<Weather> ) и наличие других классов, таких как Rain, Main, Wind, City и т. Д. c. Теперь у меня есть класс Response WeatherResponse.class data class WeatherResponse( val city: City, val cnt: Int, val cod: String, val list: List<Record>, val message: Int ) То, что я делал до сих пор

в соответствии с ответом JSON легко понять, что Weather должно быть полем внутри класса Record, но его там нет, это потому, что Weather приходит в виде списка, из-за этого я использовал внешний ключ и несколько небольших уловок (как указано в следующем ответе (Android Комната - H andling Список объектов в объекте и результат запроса ) в моих запросах Dao, чтобы сохранить список и получить список погоды в базе данных

Dao Class

@Dao
interface WetherDataDao {
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    fun upsert(data: Record)
    @Insert
    fun insert(weather:List<Weather>)
    @Transaction
    fun insert(weatherRecord: WeatherRecord){
        upsert(weatherRecord.record)
        insert(weatherRecord.weather)
    }

    @Query("Select * from Record")
    fun getAllRecords():LiveData<WeatherRecord>
}

Какая у меня проблема?

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

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

Заранее спасибо

1 Ответ

1 голос
/ 28 мая 2020

Не знаю, будет ли мой ответ полезным. Это больше о принципах, а не о практических инструкциях

Некоторые размышления

В приложении есть несколько типов групп классов данных:

  • Группа «Трансфер» . Состав этой группы формируют интерфейсы передачи. Например, у вас есть приложение Android, и есть серверная часть. У вас есть протокол JSON, вы решили использовать Retrofit, поэтому для получения данных в надлежащей форме вам нужно построить свои классы в соответствии со структурой JSON.

  • Группа «База данных» . Структура этой группы не такая строгая, но если вы используете реляционную базу данных (SQLite - одна из них), вы должны соблюдать некоторые требования. Например, вы не можете использовать другой объект в качестве поля таблицы (вместо этого просто внешний ключ) и т. Д.

  • Группа «Business logi c» . Структура этой группы практически не имеет ограничений, она должна быть эффективной для использования в ядре логики приложения c.

В простых Android приложениях все 3 группы данных могут быть реализованы с одним и тем же набором классов данных в сложных приложениях - они могут отличаться друг от друга при некотором сопоставлении друг с другом. Каждая компания могла указать какой-то шаблон, как выстроить иерархию классов. Так что, как всегда, я считаю, что здесь нет серебряной пули.

На практике :

  • Согласно вашему JSON вы должны построить определенный набор классов данных для группы «Передача» (я думаю, что это самый очевидная часть).
  • Для сохранения данных есть несколько вариантов. И это зависит от сценариев использования вашего приложения. Здесь нет необходимости, например, помещать «ветер» в отдельную таблицу (связанную с соответствующим классом данных «Передача»). Вы можете это сделать, если в этом есть смысл. Но вы также можете выбрать здесь самую простую модель - всего две таблицы «main_data» (все данные, кроме блока погоды) и «additional_data» (только блок погоды с внешним ключом к main_table). Допустим, у вас есть список Retrofit для Wind, Rain, и у вас есть только main_table в SQLite, где можно сохранить эти списки данных. Но это не проблема - в DAO вашей комнаты должна быть какая-то функция, позволяющая сохранять все данные, которые вы хотите, в вашей main_table.
  • Для ваших сценариев использования вы можете объявить другие классы со структурой, которая будет для вас эффективной (может быть, некоторые из них совпадают с вашими классами данных «Передача», а может и нет). Надо ли работать с «Ветром» или «Дождем» отдельно - ну это не проблема. Вы объявляете свои классы и используете их в запросах Room DAO как типы возвращаемого значения (две отдельные функции для одной таблицы SQLite). Вы можете объявить там классы со списками объектов как поле класса, Room может сделать это с помощью Relations .

.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...