The PrePersistHook offers this method
Optional<ItemModel> execute(ItemModel item);
When implementing the PrePersistHook the changed model is passed to the method. The executing path already open a transaction and it seems that the item is already persisted, but the transaction is not committed, yet.
If I try to get the same Item again from the database with flexible search, it returns the already updated object.
The documentation => https://help.sap.com/viewer/bad9b0b66bac476f8a4a5c4a08e4ab6b/v2005/en-US/028a2af06880407cb4b1c0624693dadd.html
defines that one should not open transactions or create new threads.
But if it is not allowed, how is it possible to get the old version of the Model in a PrePersistHook to perform a validation or perform other check before the changes are persisted?
In our case, we want to create a new version of the OrderModel, but the persisted old version ever already have the old values. We see no opportunity to get the old version in a clean way.
Many standard prepersist hooks always fetch the item again from the database and return Option.empty() in the hook
Best Regards,
Michael.
I found a solution that works for me. I override the DefaultModelEntityService and read the data before it's updated.
Related
I use the repositoryFactory in a custom plugin's Vue file in Shopware 6. When I save an entity I do this:
this.settingsRepository
.save(this.setting, Shopware.Context.api)
.then((result) => {
In case the person sends the form and this function is called, I want to get back the id of the setting in case the person hit's the save button again. But then the entity needs to be updated and not created. As I see from the response, there is an id, but it's in config.data -> json serialised.
How's the default way of solving this issue?
The best practice would be to re-fetch the entity after persisting it. This is because some entities may have fields that get automatically computed or indexed server-side and you'd probably always want to have the entity in its actual current state. If you're absolutely sure you don't want to fetch the entity again, you could manually set the _isNew flag to false after persisting:
this.setting._isNew = false;
This will then cause the save function to use the update instead of the create route. Keep in mind that this is actually kind of an internal property, as there is no setter for it and as already mentioned fetching the entity again is encouraged.
Also you shouldn't have to worry about the id. It should've already been generated client-side and set to the entity, when using the repository to create a new entity like that:
this.setting = this.settingsRepository.create();
I want to store information in some activities that are modified versions of activities imported from an existing database (ecoinvent).
I know we can add fields to activities created from scratch (example). (I guess this is because the structure of the database has not yet been defined...) but is there a way of adding it to activities of an already defined database without breaking it?
The way around I found is to add entries to the author dict, which I can easily access later on. e.g.
act['author']['scenario']='myscenario'
but I admit it is not a very elegant solution.
You can just add whatever data you want. Brightway is a (semi-)schemaless database for exactly this reason.
act['foo'] = 'bar'
act.save()
I am looking for a workaround for primary key feature in couchdb. I am saving doc in json format to couchdb externally. Is there any simple way to check if value of a particular field exists?
If you try to save a document that already exists, it will be rejected unless the revision is set to match the existing revision.
Alternately, you can just try to fetch the document, either with GET or HEAD, to check if it exists. See the relevant documentation.
You could perform a mango query previous to the document creation but it will not warranty that another process create a document between the check and the creation.
This post discusses about the same issue:
How to check for duplication before creating a new document in CouchDB/Cloudant?
I have a database called "development-records" that has a MapReduce view with a "dbcopy" declaration that creates a view in a new database called "development-chained".
When we make an update the view in "development-records", we do the usual steps of:
1. Create a duplicate copy of the design document that we want to change, for example by adding _OLD to its name: _design/fetch_OLD.
2. Put the new or 'incoming' design document into the database, using a name with the suffix _NEW: _design/fetch_NEW.
3. Query the fetch_NEW view, to ensure that it starts to build.
4. Poll the _active_tasks endpoint and wait until the index has finished building.
5. Put a duplicate copy of the new design document into _design/fetch.
6. Delete Design Document _design/fetch_NEW.
7. Delete Design Document _design/fetch_OLD.
The problem is that the documents specified in the dbcopy database "development-chained" don't seem to be updated -- all the old records stay. Is there a way to trigger the dbcopy database to perform the MapReduce again?
Unfortunately, according to the official Cloudant documentation, "The dbcopy feature can cause problems under some circumstances." Use of this feature is strongly discouraged, and has otherwise been removed from the documentation. I hope knowing that helps a little. The new documentation is hard to find.
Is it possible to manage the sync conflicts from the client?
What I mean is, when pouchDB does a sync and detects a conflict, is it possible to get the local doc PouchDB is trying to sync and the last revision of CouchDB doc? If I can get both docs, I can display them to the user and he can choose which version to keep...
You're in luck, because this is exactly the problem CouchDB and PouchDB were designed to solve.
Basically you can read up on the CouchDB docs on conflict resolution. Everything in there should also apply to PouchDB. (If it doesn't, it's a bug. ;)). The CouchDB wiki also has a nice writeup.
Edit: so to provide more details, you'll want to fetch the document with ?conflicts=true ({conflicts:true} in PouchDB). E.g. you'll fetch a doc like this:
http://localhost:5984/db1/foo?conflicts=true
And get a doc back like this:
{
"_id":"foo",
"_rev":"2-f3d4c66dcd7596419c76b2498b3ba21f",
"notgonnawork":"this is from the second db",
"_conflicts":["2-c1592ce7b31cc26e91d2f2029c57e621"]
}
Here I have a conflict introduced from another database, and that database's revision has won (randomly). This document's current revision starts with 2-, and the conflicting version also starts with 2-, indicating that they're both at the same level of the revision tree.
To get the conflicting version, you just grab the conflicting rev and call:
http://localhost:5984/db1/foo?rev=2-c1592ce7b31cc26e91d2f2029c57e621
And you get:
{
"_id":"foo",
"_rev":"2-c1592ce7b31cc26e91d2f2029c57e621",
"notgonnawork":"this is from the first database"
}
So after presenting the two conflicting versions to the user, you can then add a 3rd revision on top of both of these, which either combines the results, or chooses the losing version, or whatever you want. This next revision will be prefixed with 3-. Make sense?
Edit: Apparently you also need to delete the conflicting version, or else it will still show up in _conflicts. See this answer.