beforeUpdate in Business Logic Breaks the Default Behavior

Hi,

The default behavior of object update ( PUT ) is just to update the dirty / changed properties, I take it.
That’s working fine unless I put a beforeUpdate event handler into my business logic.
Even an empty, without a single of code, beforeUpdate handler causes total reset to the object (except the objectId) as if it’s created first time.

Is this the expected behavior?
Does implementing a beforeUpdate put all the responsibility regarding the object update to the developer?
If that is the situation, no need to read later.

If not, though, here is a little more detail about this particular project:

There is a simple contacts table in my app which holds usual suspects as e-mail, name, phone, etc.
Contacts also has a special field as Search Tokens to optimize the real-time search in the clients.
Search Tokens consists of, as you might have guessed, filtered / lower-cased / sorted keywords of all other properties.

When the contact’s created the first time, a beforeCreate handler builds this field.
But I also need to update that, whenever the contact is updated.
Here comes the aforementioned problem.
Client app sends a PUT for just the name, but Backendless throws an error as “email cannot be empty”.
Which means, most probably, Backendless expects an E-mail field but it shouldn’t; this is just an update.
When the client app sends the required fields as well, then Backendless resets all non-required fields, simply because they weren’t sent.

Again, if this is the default behavior, I can find a workaround.
I wouldn’t prefer it, but I can fetch the object in beforeUpdate, update dirty fields manually, then let Backendless save it safe and sound.

Thanks for all your help and insights.

Best,

~ Fatih

Hello Fatih

Please provide your app credentials so we could investigate the issue. And please clarify what exactly are you trying to update and in which table?

Regards Anton

Hi Anton,

AppID : E0972563-A68F-C3F2-FF50-B0F1A7DE3900
Table : QPGuest
Column : search_tokens
Type : Comma-delimited Text
Content : Sorted, filtered, lower-cased tokens from other String/Text columns of the same table.

Hi Faith,

The save/update call updates all fields of the object, except the relation ones. This is because there is simply no way the backend could determine what you’ve changed and what you didn’t change.

For example, suppose I have a table TestObjects with three String columns. The following code will first create a row with fields “a”, “b”, “c”, and then the second “save” call will set the fileds to null, null, “newone”, because t2 had them set to null.

TestObjects t1 = new TestObjects();
t1.setStr1("a");
t1.setStr2("b");
t1.setStr3("c");


Backendless.Data.save(t1);


TestObjects t2 = new TestObjects();
t2.setObjectId(t1.getObjectId());
t2.setStr3("newone");


Backendless.Data.save(t2);

Fair enough.

So, what I should do within the beforeUpdate handler is
• fetch the original/existing object from Backendless,
• update it manually determining the dirty fields (what I’ve changed and not);
• then let the system save it a whole.

Am I right?

If that is the case and the way it should be done, please feel free to mark this topic as answered.
If I misunderstood somehow, though, I’m waiting your comment.

Best,

~ Fatih

The simplest approach is just to retrieve the original/existing object, update the fields you need and then call “save” on this same object. This does not involve any business logic handlers.
Though I’m not aware of your app’s specifics, so your approach would work, too.