Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default values for new properties #157

Open
werelord opened this issue Aug 23, 2017 · 10 comments
Open

Default values for new properties #157

werelord opened this issue Aug 23, 2017 · 10 comments
Labels
feature

Comments

@werelord
Copy link

@werelord werelord commented Aug 23, 2017

Im using ObjectBox in a pet android project written in Kotlin.. I have a data class encoded as such (example):

@Entity data class Foo(var name:String, var description: String) {
    constructor() : this("", "") // parameter-less constructor
    @Id var id: Long = 0L
    // other stuff
}

Database already existed on the device.. I added an additional property to the Foo class (not in the data constructor):

@Entity data class Foo(var name:String, var description: String) {
    constructor() : this("", "") // parameter-less constructor
    @Id var id: Long = 0L
    var bar: String = ""
    // other stuff
}

defaulted, non-null object bar.. however when pulling existing records from the stored box, that value bar appears to be null.. I would expect it to be a blank string (default for the parameter); is the violation of not-null guarantee coming from the Java interop?

I fixed the issue by nuking the database; afterwords the entity created and stored is not-null.. But this brings up any possible future updates that may violate this.

Is there a "database upgrade" method for updating already stored objects between versions, adding default values to new properties, or am I resigned to make anything added to an existing model be nullable (and handle it as such)?

@greenrobot
Copy link
Member

@greenrobot greenrobot commented Aug 23, 2017

It's quite easy to trick the Kotlin non-nullable types, e.g. with JSON parsers. Same is true for ObjectBox. We will target those kind of oddities in a future version. For now, we suggest to either use nullable types, or have some update code in place. Recipe for the latter:

  1. Have a flag (via SharedPrefs for example) like "fooBarChecked"
  2. If flag is false, run a migration and set the flag
  3. Migration: run a query to get all Foos with bar == null and update the resulting list

@greenrobot
Copy link
Member

@greenrobot greenrobot commented Aug 25, 2017

Maybe an annotation for defining "defaults" for null values? E.g.

@DefaultForNull("")
var bar: String = ""

@greenrobot-team
Copy link
Member

@greenrobot-team greenrobot-team commented Apr 17, 2018

No response. Closing. -ut

@greenrobot-team
Copy link
Member

@greenrobot-team greenrobot-team commented Feb 26, 2019

Reopening to discuss default values (in Java, but also Kotlin classes with default values).

This also affects queries (merged from #589), e.g. if adding intProperty, then querying box with existing entities:

box.query().equal(intProperty, 0) // no results
box.query().isNull(intProperty) // has results

-ut

@greenrobot-team
Copy link
Member

@greenrobot-team greenrobot-team commented May 4, 2020

With 2.6.0-RC there is very initial support for a @DefaultValue annotation. Currently only String properties are supported, and only the empty string "" as default value.

Usage:

@DefaultValue("")
String exampleProperty;
@DefaultValue("")
var exampleProperty: String = ""

Edit: This annotation currently simply adds the new built-in NullToEmptyStringConverter to the property:

public class NullToEmptyStringConverter implements PropertyConverter<String, String> {
@Override
public String convertToDatabaseValue(String entityProperty) {
return entityProperty;
}
@Override
public String convertToEntityProperty(@Nullable String databaseValue) {
if (databaseValue == null) {
return "";
}
return databaseValue;
}
}

So to customize default values, create your own converter and replace @DefaultValue with @Convert.

@greenrobot
Copy link
Member

@greenrobot greenrobot commented May 4, 2020

My first assessment is that we should keep default values separate from queries. E.g. if you want to, you can query for null values.

@greenrobot-team greenrobot-team removed this from the 2.6.0 milestone Jun 15, 2020
@greenrobot-team greenrobot-team added this to the 3.0 milestone Jun 15, 2020
@pratikbutani
Copy link

@pratikbutani pratikbutani commented Aug 5, 2020

What about the default values of booleans? I had taken a boolean variable. It's giving me the default value "false" but I want true then?

@greenrobot
Copy link
Member

@greenrobot greenrobot commented Aug 5, 2020

@pratikbutani The default of booleans is false. Are you saying you experienced something else?

@pratikbutani
Copy link

@pratikbutani pratikbutani commented Oct 2, 2020

@pratikbutani The default of booleans is false. Are you saying you experienced something else?

I want default true, How can I do that?

@RobbWatershed
Copy link

@RobbWatershed RobbWatershed commented May 8, 2021

Reopening to discuss default values (in Java, but also Kotlin classes with default values).

This also affects queries (merged from #589), e.g. if adding intProperty, then querying box with existing entities:

box.query().equal(intProperty, 0) // no results
box.query().isNull(intProperty) // has results

-ut

Still present in v2.9.1 - Default values for new non-string (booleans, integers...) fields are created as null in the database.

As far as I know, our only workaround options are to :

  • Append or().isNull to all queries that use the new field
    or
  • Manually set new fields with the null value to their intended default value at app startup after the update

Having an annotation that allows to set these default values on the Entity would be a lot less cumbersome 😄

@greenrobot-team greenrobot-team removed this from the 3.0 milestone Oct 19, 2021
@greenrobot-team greenrobot-team added this to the Future release milestone Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature
Projects
None yet
Development

No branches or pull requests

5 participants