RejectedSoftware Forums

Sign up

mongo field names and document size

Would you be open to allowing annotations on fields names be recognizable by bson to support shortened names and anonymous fields?

Go supports a nice serialization feature where you can provide an additional name for the members.

birthDate int json:"bd"

The benefit is you can use meaningful names in the structures and code, but serialization can be significantly smaller. For mongo, it is not so much about performance as size of the objects. A similar approach could be elegant and a potential big size savings:

struct Person {
  @MongoName("ar") AcquiredRetired acquiredRetired;
  @MongoName("bd" Date birthDate;
  @MongoName("dd") Date deathDate;
  @MongoName("rd") Date retirementDate;
}

struct RealizedFlows {
  @MongoName("if") @MongoOmittable() TimeSeries[string] incomeFlows;
  @MongoName("ef") @MongoOmittable() TimeSeries[string] expenseFlows;
}

Would this be something you would be open to being added?

Thanks
Dan

Re: mongo field names and document size

Am 26.10.2013 18:50, schrieb Daniel Davidson:

Would you be open to allowing annotations on fields names be recognizable by bson to support shortened names and anonymous fields?

Go supports a nice serialization feature where you can provide an additional name for the members.

birthDate int json:"bd"

The benefit is you can use meaningful names in the structures and code, but serialization can be significantly smaller. For mongo, it is not so much about performance as size of the objects. A similar approach could be elegant and a potential big size savings:

 struct Person {
   @MongoName("ar") AcquiredRetired acquiredRetired;
   @MongoName("bd" Date birthDate;
   @MongoName("dd") Date deathDate;
   @MongoName("rd") Date retirementDate;
 }

 struct RealizedFlows {
   @MongoName("if") @MongoOmittable() TimeSeries[string] incomeFlows;
   @MongoName("ef") @MongoOmittable() TimeSeries[string] expenseFlows;
 }

Would this be something you would be open to being added?

Thanks
Dan

At this point I'm a bit reluctant to add any features in that direction
because of the possible addition of std.serialization. On the other it
seems like it may actually still take a while until it becomes reality.

Let me think a bit about this some more, but if we do something, it
should be something that is generally useful for serialization and not
tied to MongoDB, so maybe:

struct Person {
	@name("ar") AcquiredRetured acquiredRetired;
	@name("bd") @optional Date birthDate;
	@ignore int somefield;
}