In StatusHistory field of Transaction object there is a Source field in each element of the collection. However, the value of this field is always the same (RECURRING) - no matter what was the cause of the creation of the transaction.
How can I filter out transactions generated automatically at subcription renew from collection of all subscriptions transactions?
Related
I would like to make complex validations when save or update an Entity.
For example I'd like to check is one of the entity's property is unique, but trough complex conditions I can't declare in unique constraints.
I use #PrePersist for new entities, and #Pre/PostUpdate for existing ones. #PrePersist works well in all cases, but different errors occurred while updating existing entities.
If I inject my CRUD service into listener, and check is there any existing records based on property value I get stack overflow exception - I think because every time I call CRUD service find method Hibernate tries to update the entity before run query, and the causes SO-.
It is not a good practice to user CRUD service in EntityListener?
The other problem I don't know how to solve, if value cannot be persisted, I'd like to throw custom exception to inform the frontend about it.
If I call saveAndFlush() just my exception is thrown. But If I use just save() a TransactionSystemException is also thrown after my custom exception and that TransactionSystemException will be populated to frontend instead of my exception.
org.springframework.transaction.TransactionSystemException: Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Error while committing the transaction
How can I prevent RollbackException?
Is it a good idea at all to check these restrictions in EntityListener? My goal is to implement a layer where these restrictions automatically validated.
I would like to make complex validations when save or update an Entity. For example I'd like to check is one of the entity's property is unique, but trough complex conditions I can't declare in unique constraints.
You should probably use database that has support for this then because you will have a hard time getting this right and fast without that. PostgreSQL allows you to specify partial unique indexes, which essentially are unique constraints for a subset of the data. You can do e.g. create unique index abc on tbl (tenant_id, some_code) where deleted = false
If this doesn't work for you, you will probably have to use the SERIALIZABLE isolation level to ensure correctness, or use some kind of global lock.
Context :-
I'm validating my rest apis in spring boot. There's a transaction id that is being sent in every API call. I'm writing a custom annotation to ensure that the transaction id that is sent every time is unique. Here's an example of the request api body :-
{
"timestamp": "2020-05-12T04:15:28.318Z",
"txnid": "acscscs-4a18-11e8-96ff-05sdsadd",
"cust_id": "abc#gmail.com"
}
How do I ensure that the txnid transaction id is not repeated i.e. if I use the same transaction id twice then there should be an error thrown?
I was planning to save each transaction id to customer id map in a table, query the table to check if the transaction id is unique. Is this an efficient method?
Or is there any other efficient/simpler method to achieve the same?
You solution is fine, but the downside is database might not be the source of truth for txnid. Lets say txnid is present is saved in api but saving in database failed.
I would suggest the following solution:
Query the api for txnid on the fly (assumption: an api to provide the response HTTP.OK 200 if the txnid is present or else HTTP.NOT_FOUND 400). The api will be the only source of truth in this case.
I have an entity with created_date (updateable = false) and updated_date fields. I have #PreUpdate method where I change the updated_date value only (not change created_date), and #PrePersist method which sets new created_date and updated_date values. On Persist the created_date and updated_date are rightly persisted and the returned entity has the correct values. When I pass in the entity to merge, it rightly updates the updated_date (#PreUpdate), and I don't pass the created_date in input. In the database the right updated_date value is updated and created_date value is not changed rightly. But the returned entity has the created_date value set to null. Any Ideas why? Shouldn't the merged entity return the full entity loaded from the database?
Thanks
Sam
I think that is inline with the JPA merge javadoc.
Merge - Merges the state of the given entity into the current persistence context and returns the managed instance that the state was merged to.
(With hibernate as persistence provider) Merge starts with loading the data from the database for that entity, then copies detached entities state to the newly loaded entity. Subsequently, at a later point, during the transaction commit phase(or flush) the dirty checking mechanism fires the update query but won't include the fields marked as updatable=false.
So it doesn't attempt to reload the object with the data in the database after the UPDATE.
To trigger reload, you can rely on refresh(...) that will reload the data.
If it is spring-data-jpa it doesn't expose any refresh method, so you need to add it to your repository and and an example can be found here and discussion on this topic in the spring forum here.
Got a custom entity which has auditing enabled. Every time an user changes the stage on the Business process flow (BPF) on that entity, it's generating an audit log record with the change in the stageid which is irrelevant for the business and i cannot use the modifiedon field since the stage change is changing the modifiedon field data as well, which makes the data irrelevant for the business.
One idea would be to create a field called Business Data Modified On. Then, create a workflow that runs on change of the fields you consider to be business data and have the workflow set the new field to the current time.
It does not appear that Auditing can be disabled on the managed field StageId.
Is it possible to change which validation groups apply to say pre-update event for a short lived transaction?
i.e. tell jPA that when it commits the transaction it must apply a specific validation group to the pre-update event...
I know I can probably do this kind of validation manually - thing is I have the constraint setup and I have infrastructure to render constraint violation exceptions...
Using the following properties:
javax.persistence.validation.group.pre-persist
javax.persistence.validation.group.pre-update
javax.persistence.validation.group.pre-remove
you can specify which groups should be targeted on validation of the related events. However, these are properties which are normally defined in persistence.xml or passed as properties at entity manager factory creation time. These are not properties you can change dynamically per transaction. AFAIK there is no way to do this programattically unless you trigger the validation yourself.