Fix deserialization

[LightJack05]

• Minimizes the return schema of products to avoid inconsistent mongodb types
  Closes product_quantity may be a string (?!) #17

[Ferrari78]

Lgtm

[Copilot]

Pull request overview

This PR attempts to fix MongoDB deserialization issues by drastically reducing the Product schema from approximately 300 fields to just 4 top-level fields (_id, brands, product_name, nutriments, and nutriments_estimated). The change also removes API documentation metadata including contact information, license details, and host configuration.

Changes:

• Removed ~290 fields from the Product struct, retaining only basic identification, brand, product name, and nutritional data
• Removed Swagger API contact information, license (Apache 2.0), terms of service, and host specification
• Updated all generated Swagger documentation files to reflect the minimal schema

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.

File	Description
internal/database/product/product.go	Drastically reduced Product struct from ~300 fields to 4 fields, removing all metadata, scores, environmental data, allergens, categories, and most product information
docs/swagger.yaml	Updated API schema definition to match reduced Product struct; removed contact/license metadata
docs/swagger.json	Updated API schema definition to match reduced Product struct; removed contact/license metadata
docs/docs.go	Auto-generated Swagger documentation reflecting the schema and metadata changes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The NutrimentsEstimated struct fields are missing the bson truncate tag that is present on the Nutriments fields. According to the PR description, the goal is to "avoid inconsistent mongodb types" which the truncate tag helps with. For consistency and to prevent the same deserialization issues mentioned in the PR, all float64 fields in NutrimentsEstimated should include the truncate tag in their bson metadata, similar to the Nutriments struct fields (e.g., bson:"beta-carotene_100g,truncate").

Suggested change

	Magnesium_100g float64 `json:"magnesium_100g" bson:"magnesium_100g"`
	VitaminA_100g float64 `json:"vitamin-a_100g" bson:"vitamin-a_100g"`
	Sugars_100g float64 `json:"sugars_100g" bson:"sugars_100g"`
	Phosphorus_100g float64 `json:"phosphorus_100g" bson:"phosphorus_100g"`
	Manganese_100g float64 `json:"manganese_100g" bson:"manganese_100g"`
	Sucrose_100g float64 `json:"sucrose_100g" bson:"sucrose_100g"`
	Calcium_100g float64 `json:"calcium_100g" bson:"calcium_100g"`
	Fiber_100g float64 `json:"fiber_100g" bson:"fiber_100g"`
	Alcohol_100g float64 `json:"alcohol_100g" bson:"alcohol_100g"`
	PantothenicAcid_100g float64 `json:"pantothenic-acid_100g" bson:"pantothenic-acid_100g"`
	Carbohydrates_100g float64 `json:"carbohydrates_100g" bson:"carbohydrates_100g"`
	VitaminB9_100g float64 `json:"vitamin-b9_100g" bson:"vitamin-b9_100g"`
	Polyols_100g float64 `json:"polyols_100g" bson:"polyols_100g"`
	Magnesium_100g float64 `json:"magnesium_100g" bson:"magnesium_100g,truncate"`
	VitaminA_100g float64 `json:"vitamin-a_100g" bson:"vitamin-a_100g,truncate"`
	Sugars_100g float64 `json:"sugars_100g" bson:"sugars_100g,truncate"`
	Phosphorus_100g float64 `json:"phosphorus_100g" bson:"phosphorus_100g,truncate"`
	Manganese_100g float64 `json:"manganese_100g" bson:"manganese_100g,truncate"`
	Sucrose_100g float64 `json:"sucrose_100g" bson:"sucrose_100g,truncate"`
	Calcium_100g float64 `json:"calcium_100g" bson:"calcium_100g,truncate"`
	Fiber_100g float64 `json:"fiber_100g" bson:"fiber_100g,truncate"`
	Alcohol_100g float64 `json:"alcohol_100g" bson:"alcohol_100g,truncate"`
	PantothenicAcid_100g float64 `json:"pantothenic-acid_100g" bson:"pantothenic-acid_100g,truncate"`
	Carbohydrates_100g float64 `json:"carbohydrates_100g" bson:"carbohydrates_100g,truncate"`
	VitaminB9_100g float64 `json:"vitamin-b9_100g" bson:"vitamin-b9_100g,truncate"`
	Polyols_100g float64 `json:"polyols_100g" bson:"polyols_100g,truncate"`

[Copilot]

While reducing the schema addresses MongoDB type inconsistency issues, this approach sacrifices significant API functionality. An alternative solution would be to use MongoDB projection to selectively fetch only the required fields with consistent types, while keeping the full struct definition available for future use. This would allow the API to remain backward compatible while still avoiding deserialization errors. You could define multiple struct types (e.g., ProductMinimal, ProductFull) or use MongoDB's projection feature in the query layer to control which fields are retrieved and returned based on the endpoint's needs.

Suggested change

	}
	}
	// ProductMinimal provides a lightweight view of a product with only core fields.
	// It can be used together with MongoDB projections to fetch only these fields,
	// while the full Product struct remains available for endpoints that need it.
	type ProductMinimal struct {
	ID_ string `json:"_id" bson:"_id"`
	Brands string `json:"brands" bson:"brands"`
	ProductName string `json:"product_name" bson:"product_name"`
	}

[Copilot]

The removal of contact information, license details (Apache 2.0), and terms of service URL from the Swagger documentation represents a degradation in API documentation quality. These fields provide important legal and support information for API consumers. If this information is no longer accurate, it should be updated rather than removed entirely. Setting contact to an empty object provides no value to API users who may need support.

[Copilot]

The removal of contact information, license details (Apache 2.0), and terms of service URL from the Swagger documentation represents a degradation in API documentation quality. These fields provide important legal and support information for API consumers. If this information is no longer accurate, it should be updated rather than removed entirely. Setting contact to an empty object provides no value to API users who may need support.

Suggested change

	"contact": {},
	"termsOfService": "https://example.com/terms",
	"contact": {
	"name": "SnackLog API Support",
	"email": "support@example.com",
	"url": "https://example.com/support"
	},
	"license": {
	"name": "Apache 2.0",
	"url": "http://www.apache.org/licenses/LICENSE-2.0.html"
	},

[Copilot]

The removal of contact information, license details (Apache 2.0), and terms of service URL from the Swagger documentation represents a degradation in API documentation quality. These fields provide important legal and support information for API consumers. If this information is no longer accurate, it should be updated rather than removed entirely. Setting contact to an empty object provides no value to API users who may need support.

Suggested change

	"contact": {},
	"contact": {
	"name": "API Support",
	"email": "support@example.com"
	},
	"termsOfService": "https://www.apache.org/licenses/LICENSE-2.0.html",
	"license": {
	"name": "Apache 2.0",
	"url": "https://www.apache.org/licenses/LICENSE-2.0.html"
	},

[Copilot]

Removing the host specification from the Swagger documentation (previously "localhost:80") makes the documentation less useful for developers trying to test the API locally. While the host may vary by environment, having a default or example value helps developers understand how to access the API. Consider documenting the host configuration in a different way or providing environment-specific documentation.

Suggested change

	Host: "",
	Host: "localhost:80",