-1

I am designing a set of unit and integration tests with a friend of mine, and we had a doubt. We know the answer, at least, what is more likely to be true. However, we would like to hear your thoughts.

We are designing a test for MongoDB, and we expect that we should receive a promise, after asking to save a document. So far so good.

What about if we change the database??? can we assume for sure that all databases when queried will return a promise??

I guess regarding the _id, it depends from database to database, we are using _id from MongoDB for testing reasons.

We are using the following test using in Jest

            create://this method do exist on service, however, at the moment of testing, it is empty, just a placeholder
              jest.fn().mockImplementation((cat: CreateCatDto) =>
                Promise.resolve({ _id: 'a uuid', ...cat })
              )

The idea is to design backends that do not depend on the database, but for testing and developing reasons, we are using MongoDB and PostgreSQL.

user229044
  • 232,980
  • 40
  • 330
  • 338
  • If you want to avoid depending on a concrete interface then don't couple directly to that interface. It's not meaningful to ask if "all databases will return promises", databases don't return promises. Database libraries written in JavaScript *may* return promises, but promises are only one of many ways to return an asychronous result from a function. It's up to the authors of those libraries which method to use, if any. – user229044 Jun 09 '21 at 00:42

2 Answers2

1

Keep in mind the term promise doesn't exist as a concept for all databases, and to provide a conclusive answer to your question for all databases is not possible.

That being said, if by promise you mean the primary key or identity (in general database terms) after inserting new data, then the answer is no, there is no guarantee, not even on PostgreSQL that'll you be able to do that. It's possible for tables, even in PostgreSQL, to exist without those constraints.

Otherwise, if by promise, you mean specifically the concept in a procedural or functional language like JavaScript (as your example code in your update indicates), then yes, you should always receive a promise object if your application code is utilizing asynchronous calls appropriately.

But that would be regardless of what the asynchronous call was to whether it's a database directly (and regardless of what database system that was), an API endpoint, or another piece of application code. Also, in that case, your question (or any follow up questions) would be better suited for StackOverflow.com.

J.D.
  • 954
  • 6
  • 22
  • 2
    Thanks, they are too angry nowadays!! – Jorge Guerra Pires Jun 02 '21 at 19:30
  • 1
    @JorgeGuerraPires Unfortunately this forum is more specific than StackOverflow, because the appropriate topics are very database focussed. While your question did involve databases, and *may* be ok here, it's definitely more suitable for StackOverflow which is more general programming related, and your question was more feature specific to the JavaScript programming language (which is not very relevant here). Anyways, no worries, I'm glad I could be of help. In the future if you're unsure, posting it to StackOverflow is a good start and they'll move it here if it's more applicable here. – J.D. Jun 02 '21 at 19:27
  • "your question (or any follow up questions) would be better suited for StackOverflow.com." thanks, I am always in doubt regarding that. I have done generic questions there in the past, and they did not like. They said it is just for codes, this question sounds quite generic, I believe. – Jorge Guerra Pires Jun 02 '21 at 19:20
  • 1
    "*you should always receive a promise object if your application code is utilizing asynchronous calls appropriately*" that's not necessarily true. Although the tendency is to become more true. The old style way of handling async stuff in Node.js was using an `(err, data)` callback. There are still some APIs here and there employing that. Although, increasingly more they add promises support. And ones that don't (yet) are easily [converted to a promise](https://stackoverflow.com/q/22519784). There is even [a utility in Node.js](https://nodejs.org/api/util.html#util_util_promisify_original). – VLAZ Jun 08 '21 at 16:51
  • 1
    "*if by promise you mean the primary key or identity*" - I've never heard of that usage. Can you link some sources for that please? – Bergi Jun 08 '21 at 16:57
  • 1
    @Bergi Sorry that sounds confusing, it was based on what OP originally wrote when this was a question on DBA.StackExchange. I think his question is more clear now and I can probably clean up my answer, and incorporate VLAZ's point as well. – J.D. Jun 08 '21 at 18:06
1

Can I assume that all databases return a promise?

No. Most if not all database wire protocols are synchronous, meaning the client blocks until it gets a response. Even the databases that expose some sort of RESTful APIs are synchronous, because HTTP.

Some client-side drivers may wrap this synchronous logic and exhibit asynchronous behaviour by returning something like JavaScrpt Promises or Java Futures, but it is entirely up to the driver implementation you choose to use.

mustaccio
  • 18,234
  • 16
  • 48
  • 57