Synchronous transactions in Cordova SQLite Plugin lite4cordova - sqlite

I'm looking for a way to execute synchronous transactions with the lite4cordova plugin and can't find any example.
In the plugin's webpage there are a lot of example of asynchronous transactions, but can't find one so far.
Can anyone give me an example of how to execute a synchronous transaction? is it even supported by the plugin?

Every transaction on database has been run on a separate thread that why they implemented it in this way. All Transaction on lite4Cordova are asynchronous. If you want to make it synchronous you have to understand the native code in case of android the Java code of the plugin has to be changed.

Related

Query wait conditions with API?

Can the Control-M API be used to find out what conditions a job in the current NEWDAY is waiting on?
I realize this is a simple question, but I do not yet have access to use the Control-M API.
It doesn't look like that functionality has made it to the API as yet (not that I could see, anyway).
However, there is the ctmcontb utility (available on Server and Agent) that can be added to scripts.

Filter data from api calls in Next.js in SSG to increase performance

I vaguely remember seeing an NPM module that does this, but can't find it - is there a better way than just destructing off the api in SSG (next.js).
Use Case:
If the API is huge, many times we just pass that data INTO the "getStaticProps" not realizing this could be a performance hit if we need only a few fields and we pass in this giant payload.
Solution:
Just destructor what I need off of the api.
The solution is fine, but I remember seeing an npm that does this and sorta gives a graphql vibe and allows for nested objects/arrays etc..
What are your strategies for this?

Processing Requests in the Background

I'm writing a REST API using ASP.Net Core and Microsoft SQL Server. One of my requirements is that clients will POST certain data to this API and the API will have to transform/process the data in some way before it is used or read. Turns out this processing is costly. So I'm thinking of doing it asynchronously in the background without blocking the POST request. I'm considering doing the processing:
In a scheduled SQL job
Using a separate Windows Service running in the background that reads from the DB, does the processing and writes back to it. It'll be slower than the SQL job I presume, but the code will be more readable.
Using Hangfire. Never used it. Not sure how well it works.
What are the best options for this? Are there there any best practices around this kind of thing?
Boilerplate
Store that data somewhere (RDBMS, nonSQL, etc)
Respond to user that his data has been scheduled for processing
Run some worker or pool of workers for job processing
Store result somewhere
Notify client that background job is complete (could be just a GET /jobs/id endpoint which client can check
Show that result
You can use your own daemon, process, script. If it's not enough and you need more features use that Hangfire which is looking solid.
I am using hangfire in production for almost 3 years, and yes this is a great way, retry policy from out of the box, UI dashboard, but extra options can be like this:
Serverless (Azure function, AWS Lambda)
AWS SQS or Azure Queue + Hosted services docs
Another option I've found is to implement IHostedService, a built-in interface in ASP.Net Core. See this page for details.

Firebase - optimizing read / write

Consider a chat like implementation where clients write using a transaction on the head and read using on('child_added') listener.
When a client writes he will also get a read of the same version he sent which means a redundant transfer of that version from the database. In the case of only one connected client typing for example, all responses to the listener will be redundant.
I tried to optimize this by turning off the listener before writing and turning it on again when writing ended with a startAt(new head). This way I don't get the redundant read of the location that was sent.
This all works fine but I now don't know if the cost of removing and adding the listener may be high as well ? what is the best strategy here ?
Firebase automatically optimizes it for you. This is pretty much the standard use case; it's what Firebase was designed for. The best strategy is to leave the listener on. Let Firebase do its thing.

Firebase Database Migration

Coming from a SQL background, I'm wondering how does one go about doing database migration in firebase?
Assume I have the following data in firebase {dateFrom: 2015-11-11, timeFrom: 09:00} .... and now the front-end client will store and expects data in the form {dateTimeFrom: 2015-011-11T09:00:00-07:00}. How do I update firebase such that all dateFrom: xxxx and timeFrom: yyyy are removed and replaced with dateTimeFrom: xxxxyyyy? Thanks.
You have to create your own script that reads, transform and write it back. You may eider read one node at the time or read the whole DB if it is not big. You may decide to leave the logic to your client when it access to it (if it ever does)
I think you are looking for this: https://github.com/kevlened/fireway
I think is a bad idea to pollute a project with conditionals to update data on the fly.
It is a shame firestore doesn't implement a process for this as it is very common and required to keep the app and db in sync.
FWIW, since I'm using Swift and there isn't a solution like Fireway (that I know of), I've submitted a feature request to the Firebase team that they've accepted as a potential feature.
You can also submit a DB migration feature request to increase the likelihood that they create the feature.

Resources