Announcement

**Isomorphic** · 12 Feb 2025, 10:50

Additional criteria beyond a PK cannot do anything since the PK is already unique. Perhaps the PK is faked here (not really unique) and you set allowMultiUpdate to hack around this? Because it’s correct for allowMultiUpdate to not attempt cache sync.

**claudiobosticco** · 12 Feb 2025, 13:19

Hello, I believe there has been a change in behaviour that unfortunately breaks my code.

First, I'd like to confirm something.

I noticed that the documentation states:
"Note, in the case of doing an update or delete operation with a primary key and additional criteria, allowMultiUpdate must be set or additional criteria will be dropped and just the primary key fields will be used in criteria."
starting from version 12.1 onward. However, this only applies to DSRequests constructed on the server side. That is, if an update comes from the client and I add criteria in a DMI, those criteria are always retained. Is that correct?

Now, going back to the logs from my first post, which were generated by my (rather old) piece of code: in those logs, allowMultiUpdate=true is not set. However, if I use version 13.0-p20240810 (which produces the first log) and call dsRequest.getAllowMultiUpdate(), it returns false, whereas in the latest 13.0 version (which produces the second log), it returns true, and indeed, the extra criteria are not removed.

I have now discovered that this happens because the DSRequest is constructed without an RPCManager, but with a DSTransaction: if I create it with an RPCManager instead, then the extra criteria are ignored. Is it a bug?

As for why I have server-side code adding these criteria: as far as I remember, it's to avoid updating a record that someone else has already updated before me, or maybe to avoid someone updating a record which he shouldn't update.

Would it be possible to have a flag to allow this behaviour (and without enabling allowMultiUpdate)? Essentially, to have it behave as the dsRequest is a client request.

**Isomorphic** · 18 Feb 2025, 06:22

OK, multiple things to clarify here:

1. we can't really figure out what you mean about dsRequest.getAllowMultiUpdate() returning false - it's not clear if it's correctly returning false (because you didn't set the property) or not, but it also sounds like it's behaving as expected, so let us know if you are reporting something as wrong here

2. client-side "update" requests indeed limit criteria to the primary key, but this behavior is very old, not from 12.1. There was, however, a documentation clarification which was added to 12.1 and prior versions (with no behavior change).

3. server-created requests do allow additional criteria (with or without allowMultiUpdate=true)

4. providing an RPCManager to a DSRequest causes it to be treated like a client-side request, that is, it is subject to the same security restrictions as client requests. This includes having additional criteria, and this is as documented and as designed. You can, however, override this (dsRequest.setClientRequest(false))

5. It sounds like you are hoping for extra criteria from the client to be allowed, but you don't want to have to set allowMultiUpdate: true, since aside from that being dangerous, it also turns off cache sync. Is the correct?

As far as how to handle this, with the existing system, you could either:

1. setClientRequest(false) to remove security constraints - but keep in mind this removes all security constraints. For example, the request might omit the PK and a mass update / mass delete would be allowed

2. just perform cache sync yourself, which is nearly a one-liner, roughly: return new DSRequest("fetch", [provide the PK as criteria]).execute()

We could possibly just add an additional flag, something like allowExtraCriteria, which allows client-submitted requests to apply additional criteria. However this is a fairly substantial task, so we would only tackle it via Feature Sponsorship.

**claudiobosticco** · 19 Feb 2025, 14:34

Hello, for now let's stick to the problem from the first post. It's a server-side DSRequest, ie in a DMI I've got code like:

Code:

        DSRequest dsRequest = new DSRequest("JTK_ACC_UTENTI", DataSource.OP_UPDATE);
        dsRequest.setDSTransaction( dsTransaction);
        dsRequest.setCriteria(criteria);  // criteria with pk and additional criteria
        dsRequest.setValues(values);
        DSResponse dsResponse = dsRequest.execute();

and allowMultiUpdate is not set.

Code like this, in 12.1 was generating an update which contains all criteria in the where clause, and was also returning the updated record in the dsResponse.

It was also behaving like that in v13.0p_2024-08-10/Enterprise Deployment, but in the latest 13.0, after the update with additional criteria, it's logging:

Code:

DSRequest This update request on dataSource 'JTK_ACC_UTENTI' is for operationBinding 'null', which is marked allowMultiUpdate: true. No cache synchronization will be run.

So the dsResponse doesn't contain the updated record. It isn't easy for me to catch all the places in my code where I could possibly have this issue.

PS: about the other points, I think it'd be better if I start some new threads.

**Isomorphic** · 2025-02-20T16:41:17

We have today committed a fix for this change in behavior, on all branches from 13.0 upwards. The fix should be in as of tomorrow's builds, dated February 21st or later. Please check and confirm that your use case now works as expected.

Announcement

No cache synchronization with additional criteria in update

Comment

Comment

Comment

Comment

Comment