A query builder for PostgreSQL, MySQL and SQLite3, designed to be flexible, portable, and fun to use.
But I wouldn't do that query as a loop, but would just do single query that select all hospitals nearest to that position (limited with maximum radius), order them by distance or something like that. It is easier to avoid using stored procedures with knex / objection unless there are some real performance issues that requires them.
@elhigu Thanks. But I just want to make sure that I get atleast one hospital as the result. If I give a one static radius then I can't make sure I get a hospital every time. Actually I'm doing the same thing like you said but if I dont get a result, then I increase the search radius
So wouldn't it be then the same to search with radius that covers all world, order by distance and limit result to for example 100 nearest or so? I mean if that radius limit is meant to make query faster, because there are less hospitals to check I don't thing it helps at all. AFAIK to know if each hospital is near to that point, PG still have to calculate the distance between that point and hospital location for ALL hospitals in the table.
Maybe one way to make that kind of query fast is for example to decide that world has 1000-10000 hospital clusters and each cluster has their center and radius. Then you can more easy limit the results so that accurate distance calculation is done only for those hospitals, which belongs to nearest clusters. But if there is only less than 100k hospitals to check that kind of clustering might not be necessary... Also there probably is some better ways to do that optimization (maybe postgis has some special graph index for that which allows to do rough checking automatically for limiting results) so that clustering is not necessary for even huge amount of hospitals.
I have been struggling lately with a situation on knex, can I get a hand? I posted the issue on SO but no-one has helped so far.
async function service() {
await createElements(list); // insert x elements from the list
const elements = await getLastXInsertedElements(userId, list.length)
await useElementsIdAsForeignKey(listMakingUseOfElementsIds);
}elements it does not always contain the complete list of elements that was just inserted, that leads me to believe that for some reason knex does not return when the operation has finished but rather when the operation started (when the bulk insert started)
if you want to see what is behind those functions, you can check the SO link
We just opened a PR about this: Vincit/knex-db-manager#89
@elhigu what do you think about it?
hi all... I'm killing myself here trying to get migrations working with typescript... none of my imports in my knexfile work when my tsconfig.js module is "es2020"; however, if i change the tsconfig.js module to "commonjs" the imports work just fine... here is a gist of my setup as well as some console logs showing what i mean(connectionProperties in line 5 from knexfile.ts is showing up undefined)
Complete rewrite....uhhhh....knex is way too big and complex
Complete rewrite....uhhhh....knex is way too big and complex
I don't see it impossible... there is lots of stuff that could be deprecated and internals should be done in a different manner anyways (having internal AST of built query to be able to inspect and modify it easier).
Knex actually is not so complex either... or at least it shouldn't be. It should be really straight forward set of APIs that construct AST and compiler plugins, which build DB specific queries from that AST :sweat_smile:
But I do have several years of typescript behind me, I can't really remember how difficult to learning curve was
With typescript you'll know what properties you have, for instance
Is there a public roadmap I could take a look at?
Or are you guys just winging it
But generally I'm not against typescript especially with end application code I am just not sure if it would be beneficial with knex or not. Maybe it would. Though also from objection we know that trying to type query builder return value depending on builder chain is really tricky
I'm blanking on his username, but who made it did a good job with the generics
Yeah that was him
Hi, I think the Travis CI pipeline seems to be broken now. Please see https://travis-ci.org/github/knex/knex/jobs/702942826
Hey folks and thanks for the work you've put into knex! I collaborate with @issa-tseng and wanted to give a little context for how the bug fixed at knex/knex#3900 manifests for our project. We work on ODK, a set of open source tools for data collection in resource-constrained environments (https://github.com/getodk/central-backend is the component that uses knex). The deep dive @issa-tseng documented on the issue came out of the connection leak leading to failures for a field partner doing COVID-19 contract tracing in Subsaharan Africa. All this to say that this is a case where code review can have big positive impact!