Ignore null properties by default

[Turnerj]

Effectively default the behaviour of BsonIgnoreIfNull on all properties. If I understand it correctly, there shouldn't be any noticeable impact from this change besides less data in the DB.

More research may need to be done and asked about directly to MongoDB themselves.

Pros

• Less storage used by MongoDB
• Less data to send down the wire (AFAIK null properties are still sent - may depend on the driver)

Cons

• If you depend on null being saved (which is definitely possible), it obviously won't which would break things. At minimum would need a way to opt-out of default ignoring of null values - whether that is MongoFramework-wide or type-wide would still need to be determined.

Notes

• No known impact for querying performance in the DB because of ignored properties (eg. doesn't seem to impact indexing)

[NO1225]

I think making this optional will be more appropriate I have this case which will be impacted with such a decision I have made dynamic content which will be created dynamically using a dynamically created schema The fields may be required and may be nullable In case of nullable fields, I still need the key to be returned when returning the content to the front end so that the schema of a content stay somewhat consistence In case the ignore null by default was enforced, I will have to get also the schema and compare and attach any null field key to the returned object, which may be cumbersome in case of a paginated list of data Thank you

[Turnerj]

Hey @NO1225 - thanks for mentioning this. It is an interesting usecase and would love to know more about it. Is there any more information you could share about it?

With what you're saying, it does sound like at minimum I'd want a way to opt-out of "ignore if null" if I did pursue it.

[bobbyangers]

Hi @Turnerj, Would be complicated to apply the default attributes from the Mongo Driver BsonIgnoreAttribute BsonIgnoreIfNullAttribute BsonIgnoreIfDefaultAttribute BsonDefaultValueAttribute BsonDateTimeOptionsAttribute BsonSerializerAttribute ...

[Turnerj]

Hey @bobbyangers - MongoFramework actually used to support that back in 2019. I've since removed that support as MongoFramework has its own mapping system which is more flexible.

What my plan was with this issue was finding sensible defaults that avoided unnecessary data storage and network bandwidth. If the majority of the time it doesn't matter if null is serialized or not, I'd opt for not having it serialize.

[bobbyangers]

But about if one wants to implement a functionnality that inherits from BsonSerializerAttribute or BsonDateTimeOptionsAttribute ?

[Turnerj]

But about if one wants to implement a functionnality that inherits from BsonSerializerAttribute or BsonDateTimeOptionsAttribute ?

Currently you can't - at least not via those attributes. You can add custom mapping processors in MongoFramework and maybe you could make it use those attributes etc but that isn't possible by default.

While MongoFramework runs on top of the MongoDB Driver, it isn't a light shim for the inner workings of the driver. To do some of the functionality in MongoFramework, I've needed to make decisions on where compatibility starts and stops. Where there is a strong need, I might attempt to include matching functionality however I'm aiming for the most common use cases first.

[NO1225]

Sorry for the late response, Yes a way to opt out is perfect for my scenario

To cover the case completely, i have a dynamic content system, The structure of the Content Item itself is defined in another collection, and the structure will contain the fields of the content item, field options and type, one of the field options is that if the field is required or not, When creating a content item, you have to choose which structure this content item adhere to, and if there is a nullable fields in that structure, these values may be saved as null in the content item,

The problem when these null values are ignore is that when returning this content item, some of the fields will be missing and i can't ensure the structure of the content item unless i validate with the structure when reading, which will take time and oppose the purpose of saving it as a read ready item

Note: Let me say that i'm a huge fan of this library and using it saved me a lot of time and effort, A big thank you isn't enough

[Turnerj]

Sorry for the late response, Yes a way to opt out is perfect for my scenario

All good mate! It is the holidays for most of the world, you don't need to get back to me instantly.

To cover the case completely, i have a dynamic content system, The structure of the Content Item itself is defined in another collection, and the structure will contain the fields of the content item, field options and type, one of the field options is that if the field is required or not, When creating a content item, you have to choose which structure this content item adhere to, and if there is a nullable fields in that structure, these values may be saved as null in the content item,

The problem when these null values are ignore is that when returning this content item, some of the fields will be missing and i can't ensure the structure of the content item unless i validate with the structure when reading, which will take time and oppose the purpose of saving it as a read ready item

That sounds like a very interesting project. Is this part of an internal project or maybe an open source tool? (This is for my own curiousity as it sounds pretty cool)

OK, I see what you mean here with the structure. That makes sense to me and will update the issue description accordingly noting that it should (at minimum) have an opt-out. You won't need to worry about this being done in the short term though, this particular issue is more of a backlog item for me.

Note: Let me say that i'm a huge fan of this library and using it saved me a lot of time and effort, A big thank you isn't enough

Thanks!

They say you miss 100% of shots you don't take so... if it is really beneficial to you and you (or the company you work for/with/that is using it etc) could financially contribute, that would be pretty awesome. I do offer support plans which can be helpful for businesses or even just a little something via GitHub Sponsors can go a long way.

If you can't do that, spreading the word about MongoFramework (and/or any of my other projects) can also be helpful for the long term sustainability of my OSS projects.