Validation can happen on client side and server side, what if it happens on db side, if I want to stop an insert/update by rollback in trigger, how do I notify the client side, now it seems breezejs just ignore my error raised in trigger.
If you are using an Entity Framework or NHibernate backed server, then throwing any exception on the server should fail the entire transaction and turn into a failed save on the client ( with all changes placed back into their 'presave' state). In order for this to occur the Breeze server must detect an exception. You may need to have your trigger to raise an exception.
If you are using some other server, the behavior depends on whether the database supports tranactional semantics. ( for example MongoDB does not).
Found it does return, just need set severity to higher and parse error message from http data.
Related
We do a lot of real-time data where I send a WebSocket message to the client when a record is updated. I've been hooking into "after_commit" to send those messages. That, of course, makes sure the record is in the database but can cause problems if the client tries to use that message to rerun an ES query (no guarantee that it's indexed yet). Is there anyway for my API to hook into the ES lifecycle and wait to send the websocket message until the record has been indexed?
I know searchkick has sync mode but I don't want to make the user wait for indexing. Right now we just have the client wait for one second to retrigger the search query but is there any way to know exactly when it's done?
Any thoughts? Thanks!
The subject is:
I have connected one of my processes to an external sql database through Database Connection( very hard of course due to lack of sql connection!). In my dynaform i have two textbox that are named RefNumber and Value and also i have a button. i want to enter a number in RefNumber and press the button and related value to that number appears in Value (i have that number and its corresponding value in my database that i earlier connected).
So the first question is : Which one should i use ?Trigger or Javascript?
and the second question: what is the code?
Any comment is appreciated.
It depends on you whether you want to update your value at database side or backend side.
Also I would like to add that trigger sometimes fail due to bad connection issues or some random user shit error and it might happen that your data is updated and value is not incremented(updated). So I recommend not to use trigger, yes trigger saves time but sometimes it doesn't work.
And benefit of doing it at backend side is that if your data is not updated, failed, value will also not.
My solution is to create an API on server app processmaker(use plugin to create api). Or the server BackEnd will configure CORS enabled so that the client side can call the api.
In dynaform, use ajax to make request to api.
I want to send detailed info about exceptions from a DCOM server to client. Today we already have a log in server, but it would make our lives simpler having both callstacks (client and server) in the same log in client.
We achivied to do this by making a second call to server after the exception, to get the log, but it would be better to not have this second call, and send togheter with the error.
The error arrive in client with an object of TExcepInfo (tagEXCEPINFO). This struct does not have any specific field of a "detailed log", or additional info. It does have an bstrSource field that I could use, I think.
My question is: is there a "best practice" to do this, or some specific field meant for it, or could I just use this bstrSource? Or maybe send in the bstrDescription, that is where the exception message goes, and split this in client, something like that?
PS.: Delphi 5. We have a migration to Delphi Tokyo, but the solution have to be for both of then.
So, super weird use case.
Basically, a client created objects and syncs them to the server. The server persists them, and returns that same object with a UID. When the client gets that UID object, it deletes the client version and saves the server version.
I’m worried that the client will send the object, and while the server is validating, disconnect. Then when the client sends the object again, we have duplicates.
I could generate a client ID to avoid his situation and persist that with the server object, but I was looking into a way to only persist objects if the client successfully receives the response, so we know it won’t resend the request
I googled around, but I couldn’t find anything. Is there a way to do this?
So, as I thought, my answer really demonstrates a lack of understanding on how HTTP works. I suspected that it wasn't possible with this technology - and it isn't - but there's really an underlying problem that I should have addressed.
The correct answer is to have an id generated on the client that is also stored in the database. The reason is because this makes the request idempotent - that is, the client can resend the same request as many times as it likes without messing up the server.
Whenever the server gets a request to make a new object, it simply checks our client ids sent. If that object already exists, don't make it again, just return the server generated object. Simple!
we're using CometD 2 to achieve the connection between a central data provider and several backends consuming the data. Up to now, when one of the backends fails briefly, all messages posted in the meantime are lost. Now we heard about the "Acknowledge Extension" for CometD. It is supposed to create a server-side list of messages and delivers them when one of the clients reports to be back online. Here are some questions:
1) Does this also work with several clients?
2) The documentation (http://cometd.org/documentation/2.x/cometd-ext/ack) says: "Note that if the disconnected browser is disconnected for in excess of maxInterval (default 10s), then the client will be timed out and the unacknowledged queue discarded." -> does this mean that in case my client doesn't restore within the maxInterval, the messages are lost anyway?
Hence,
2.1) What's the maximal maxInterval? Which consequences does it have to set it to a high value?
2.2) We'd need a secure mechanism for fail outs of at least a few minutes. Is this possible? Are there any alternatives?
3) Is it really only necessary to add the two extensions in both the client and cometD server? We're using Jetty for the server and .NET Oyatel for the client. Does anyone have some experiences with this?
I'm sorry for this bunch of questions, but unfortunately, the CometD project isn't really well documented. I really appreciate any answers.
Cheers,
Chris
1) Does this also work with several Clients
Yes, it does. There is one message queue allocated for each client (see AcknowledgedMessagesClientExtension).
2) does this mean that in case my client doesn't restore within the maxInterval, the messages are lost anyway?
Yes, it does. When the client can't reach the server for maxInterval milliseconds, the server will throw away all state associated with that client.
2.1) What's the maximal maxInterval? Which consequences does it have to set it to a high value?
maxInterval is a servlet parameter of the Cometd servlet. It is internally treated as a long value, so the maximal value for it is Long.MAX_VALUE.
Example configuration:
<init-param>
<!-- The max period of time, in milliseconds, that the server will wait for
a new long poll from a client before that client is considered invalid
and is removed -->
<param-name>maxInterval</param-name>
<param-value>10000</param-value>
</init-param>
Setting it to a high value means that the server will wait longer before throwing away the state associated with a client (from the time the client stops contacting the server).
I see two problems with this. First, the memory requirements of the server will potentially be higher (which may also make denial of service easier). Second, the RemoveListener isn't called on the Server before the maxInterval expires, which may require you to implement additional logic that differentiates between "momentarily unreachable" and "disconnected".
2.2) We'd need a secure mechanism for fail outs of at least a few minutes. Is this possible? Are there any alternatives?
Yes, it is possible to configure the maxInterval to last for a few minutes.
An alternative would be to restore any server side state on every handshake. This can be achieved by adding a listener to "/meta/handshake" and publishing a message to a "/service/" channel (to make sure only the server receives the message), or by adding an additional property to the "ext" property of the handshake message. Be careful to let the client restore only valid state (sign it on the server if you must).
3) Is it really only necessary to add the two extensions in both the client and cometD server?
On the server it is sufficient to do something like:
bayeux.addExtension(new AcknowledgedMessagesExtension());
I don't know how you'd do it on Oyatel. In Javascript it suffices to simply include the extension (dojo.require or script include for jQuery).
When a client with the AckExtension connects to the server, a message similar to the following will be logged (from my Jetty console log):
[qtp959713667-32] INFO org.cometd.server.ext.AcknowledgedMessagesExtension - Enabled message acknowledgement for client 51vkuhps5qgsuaxhehzfg6yw92
Another note because it may not be obvious: the ack extension will only provide server to client delivery guarantee, not client to server. That is, when you publish a message from the client to the server, it may not reach the server and will be lost.
Once the message has made it to the server, the ack extension will ensure that all recipients connected at that time will receive the message (as long as they aren't unreachable for maxInterval milliseconds).
It is relatively straightforward to implement client-side retrying if you listen to notifications on "/meta/unsuccessful" and resend the message (the original message that failed is passed as message.request to the handler).