[amdo]

#androiddev
Lekcja na dziś:
Robiąc bazę danych ormlite w przechowywanej klasie nie przypisujemy wartości do zmiennych. (tak jak w ostatnim polu)

@DatabaseField(generatedId = true, columnName = "id")
private Long mId;

@DatabaseField(columnName = "hour")
private int mHour;

@DatabaseField(columnName = "minute")
private int mMinute;

@DatabaseField(columnName = "active")
private boolean mIsActive = false;

parę godzin na szukanie błędu i kombinowania co zrobić żeby działało poszło się #!$%@?ć, nie popełnijcie tego błędu!

[M4ks]

Lekcja na dziś:

Robiąc bazę danych ormlite w przechowywanej klasie nie przypisujemy wartości do zmiennych. (tak jak w ostatnim polu)

@amdo: raczej - uczymy sie jak dziala ORM ( ͡° ͜ʖ ͡°)

[amdo]

@M4ks: zapamiętam to na zawsze :)

[AndroidKuc]

czemu nie Realm?( ͡° ʖ̯ ͡°)

[shus]

@AndroidKuc: Gwałci zbyt wiele zasad dobrego kodu oraz jest zbytnio gloryfikowany przynajmniej obecnie. Ogólnie nadaje się na hobbystyczne aplikacje ale klientowi nigdy bym go nie zaproponował.

[shus]

@amdo: Ogólnie dawno nie korzystałem z ormlite ale wydawało mi się że twój sposób powinien zadziałać (bądź tylko z typem Boolean to działa). Jak jednak ja się mylę zawsze możesz użyć typu Boxed (Boolean) i w adnotacji dać że nie zezwalasz na nulle oraz 'defaultValue' jest "true" {Tak to jest string, tak wiem że to nieładne}.

[AndroidKuc]

@shus "zawsze się trochę gwałci" Powiedz gdzie konkretnie realm gwałci dobry kod? denerwują cię gettery i settery? czy niewygodna migracja?

[shus]

@AndroidKuc: Prawdopodobnie zostanie to poprawione niedługo ale nie możemy mieć modelu z własnymi metodami - tylko standardowe gettery i settery które muszą mieć określoną nazwę. Problemy z wielowątkowością (która w sumie niedawno się dopiero pojawiła). Ponadto mamy konieczność dziedziczenia obcego objektu do naszego modelu co często może boleć. Ogólnie Jake W. cośtam naskrobał odnośnie realmu więc możesz przeczytać dlaczego nie uważa ją za dobrą bazę. Żeby była jasność sam korzystam z