Releases: trebol-ecommerce/trebol-backend-monolith
Releases · trebol-ecommerce/trebol-backend-monolith
v0.2.2
Changed
- Update GitHub issue templates, contribution guidelines and reformat
*.md
files - Removed properties in
pom.xml
that were only used once - Updated project dependencies
- lombok
1.18.24
->1.18.26
- h2 database
2.1.212
->2.1.214
- lombok
Fixed
- Missing validation for request bodies of
PUT
methods in/data/*
controllers
v0.2.1
Changed
- Project-wide clean up (re-indentation & import optimization)
- New indentation rules set in
.editorconfig
- New indentation rules set in
Fixed
- Raise an exception when no payment type is specified during checkout
- Unintended errors during checkout
- Description of each sell detail would not be included
- New sales would not have an initial status or registered payment type
- Billing address was required for non-enterprise customers
v0.2.0
Added
- Support for partial updates using
PATCH
request in these endpoints/data/products
/data/sales
/data/users
/data/images
/data/product_categories
/data/shippers
/data/product_lists
Changed
- Update
CrudService
signature methodsupdate
- now meant as a method to fully update a data registry or itempartialUpdate
- new method; meant to update part(s) of a data registry or item (former behavior of theupdate
method)
- Update
PatchService
signature methodspatchExistingEntity
method relies on aMap<String, Object>
as first parameter, instead of a<P>
object- The previous method signature has been deprecated in favor of this one
- All
@Entity
classes implement a newDBEntity
interface- This interface declares a getter & setter pair for an
id
field. Most entities already had one anyway. - This is made to easily integrate the
partialUpdate
method with database numeric primary keys, represented by thefindById
repositories
- This interface declares a getter & setter pair for an
- Update base
CrudGenericService
implementationpartialUpdate
method is implemented, being fully-aware of theDBEntity
interface to pass theid
to an existing target entitycreate
andupdate
methods now share extremely similar logic- Their only difference is that the
update
method syncs the entityid
before being saved and flushed
- Their only difference is that the
prepareEntityWithUpdatesFromPojo
renamed toflushPartialChanges
- Remove method
prepareNewEntityFromInputPojo
- Instead of overriding this method, implementations may directly override its containing
create
method
- Instead of overriding this method, implementations may directly override its containing
- Remove method
persist
- This two-line method started making things a bit confusing... (!?)
- (note to self: never excuse a two-line method to duplicate code refactoring)
- Scope and flows of data have changed
- Entity classes' copy constructors are very often used, so now these never care for entity relationships
- EXCEPT when it is explicitly stated otherwise! These exceptions were made (from-to):
Customer
->Person
Salesperson
->Person
Sell
->SellStatus
Sell
->PaymentType
Sell
->BillingType
User
->UserRole
- EXCEPT when it is explicitly stated otherwise! These exceptions were made (from-to):
ConverterService
s now take care of one-to-one entity relationships at mostCrudService
s now take care of all entity relationships not covered by other cases- Pojo classes with
id
fields have been stripped of them; only entities holdid
fields now
- Entity classes' copy constructors are very often used, so now these never care for entity relationships
Fixed
- Calls to
/checkout
using an invalid sell will output a400
error (bad input from user) instead of500
(bad state of the server) - Add a check in two
GenericCrudService
methods,partialUpdate
andupdate
, both overloaded with a QueryDSLPredicate
as a second method argument- Validate that said
Predicate
only ever matches one record - This behavior could change in the future, but for now it is a deliberate choice to avoid them affecting more than one registry at a time
- Validate that said