1) Does inventory material transaction ID get populated when any standard transaction is made in oracle install base.
2) I defined a custom transaction type and passing that to public API,at that time material transaction ID is not getting populated.
Please let me know whether material transaction ID is populated only to standard transactions or also for custom transactions
For each and every transaction done in Inventory material transaction ID is populated that you can check in Inventory >> transactions >> material transactions..
Related
Imagine the following situation: We have two database tables, Tenant and House. Tenant references House with a #ManyToOne mapping.
Tenant tenant = tenantRepository.findById(id).orElseThrow();
House house = tenant.getHouse();
house.setPrice(340_000);
house = houseRepository.save(house); // A new instance is returned by the CrudRepository::save() method
// TODO Is this necessary for further use?
tenant.setHouse(house);
// Further use...
tenant.setAge(23);
tenant = tenantRepository.save(tenant); // Otherwise it is saved with the old reference where house's ID can be null?
...
Is it necessary to update the Tenant with the new reference of House?
EDIT: For clarification, you may assume the entities were loaded (therefore, in managed state) immediately before the above code. And because this "transaction" is a part of a Spring #RequestMapping function, the transaction will be implicitly committed in the end of it.
EDIT 2: The question is not whether I should or not save the house at all in the beginning to avoid this situation. It is about understanding better how the objects are managed.
--- But you may tell me also, should I just update everything first, and save in the end, as a common practice?
The critical question is are house and tenant already managed entities?
If yes (because they got loaded in the same transaction that is still running) all the House instances involved are the same and you don't need to set the house in tenant.
But in that case, you don't even need to call save anyway.
If they are detached instances, yes you need to call tenant.setHouse(house);.
Without it, you will get either an exception or overwrite the changes to house, depending on your cascade setting on the relation.
The preferred way to do all this is:
Within a single transaction:
Load the entities
manipulate them as desired
commit the transaction
JPA will track the changes to the entities and flush them to the database before actually committing the database transaction.
I have 2 types of transaction :
orderrequest ( provide details including orderer name and transaction id )
ordereraccept (provide id of the orderrequest transaction being accepted)
within the transaction processor function of orderaccept i want to refer to the previous orderrequest transaction using the id to perform validation
i was thinking of using some form of historian but have not been able to get anything to work .
In the test section of composer playground i am able to view previous transactions so I just need a way to do this within a transaction processor function
Thanks a lot
Getting stuck while making transaction on composer-playground. Github Link. It throws the error
t: Instance org.hcsc.network.Commodity#ts1 has property company with type org.hyperledger.composer.system.NetworkAdmin that is not derived from org.hcsc.network.Trader
In your definition of Trace you have a --> Trader company, and in your code you assign me (current participant) - BUT you have processed the transaction using an ID that is bound to the Network Admin (org.hyperledger.composer.system.NetworkAdmin)
You need to run the transaction as a Trader
Create a new Trader participant
Issue an ID to the participant
Select and use that ID
Run the transaction
BTW I notice that you are using a new Date(); in your transaction - this is an example of a 'non-deterministic' value, and when you move to a multi-peer configuration this will fail. It will fail because when the Fabric runs the transaction on Multi-peer and tries to find consensus, the timestamps will be fractionally different on each peer and the transaction will be rejected. For the same reason you can't use random numbers in transactions.
To the question "Save Differences with Entity ID" I found the following answer:
"For Entities, Id property cannot be null, so you need to map this class as ValueObject. If so,
Id property is treated as regular property and it not goes to GlobalId of this object."
My question is:
Why can't an entity be treated as NEW if the Id is NULL?
I have an object graph that is fetched from the database, and between two javers commits an entity is added to a list in the graph.
Two commits and in the second commit there is a new entity (Id NULL)
Get the change => exeption because Javers can't create a GlobalId.
I can get arround this by doing EntityManager - persist (creates Id:s), but I would like to avoid doing that. The present code may do a persist later or it just lets the transaction finish.
Because the Id is NULL, the entity is NEW. Would it be possible to generate a unigue temp Id (allow Id = NULL) to be able to create the GlobalId?
In the change list, the entity would be reported as NEW. No need to compare with earlier commits.
You should compare/commit your objects when they are fully initialized so when they have Ids.
An entity without Id can't be handled by JaVers for several reasons:
it can't be compared to other entity/version (diff algorithm is based on GlobalIds)
it can't be queried from JaVersRepository (queries use GlobalIds)
If you are using Hibernate, compare/commit your new objects after Hibernate assigns them Ids from sequences.
Another options:
don't use sequence-generated values as JaVers Id but some business identifiers
if an Entity doesn't have a business identifier you can generate UUID in a constructor and use it as JaVers id (and also database PK if you like)
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.