Litdb – type safe SQL for JavaScript/TS

Post by jeswin » Fri, Dec 06, 2024, 5:05 AM UTC

maxloh wrote: post #39

jeswin wrote: post #36

This looks great. But in my view there's still some scope for improvement in expressive-ness (compared to something like LINQ). A future area of exploration could be to add a parser to the mix, so that we can write: const jane = db.contacts.one(c => c.email === janeEmail); instead of: const jane = db.one ($.from(Contact).where(c => $`${c.email} = ${janeEmail}`))! The former is so naturally typesafe, without having to…

That won't be possible without a lot of work. You'll need to tweak the TypeScript compiler to make the parser comprehend exported variables. For example, import { contacts } from "db" const jane = contacts.one(c => c.email === janeEmail) Marco-like magic can be confusing, as we learned from Svelte. Especially when it's half-baked like the one you are suggesting. Another drawback is that you'll need to compile the cod…

Post by jeswin » Fri, Dec 06, 2024, 5:16 AM UTC

mythz wrote: post #42

jeswin wrote: post #40

Earlier quoted context omitted.

> It's an intentional decision that drivers are decoupled from the Application and query builder it executes, i.e. all driver APIs provide different ways of executing SQL + Params or a function that returns SQL + Params (Query Builder). This allows drivers to flexible to exec (non-litdb) SQL/Params or Query builders from a different library. But my suggestion doesn't couple the driver and the Application/query builde…

> The broad applicability of this approach has been proven to work by EF being the defacto DB access method in the .Net work (over 15 years now). It's only the defacto DB access method in .NET because that's what Microsoft's EF library chose and .NET ecosystem just uses the default MS option but EF's influence doesn't extend outside of .NET. AFAIK no other .NET ORM does this including our .NET ORM [1] which litdb is…

Post by retropragma » Fri, Dec 06, 2024, 5:46 AM UTC

aethr wrote: post #26

mythz wrote: post #24

Earlier quoted context omitted.

litdb does include support for registering TypeConverters for mapping custom RDBMS types [1]. The drivers doesn't include any converters for custom RDBMS-specific types yet, but you should be able to register your own in your App or even better submit a PR to the postgres driver [2] so it'll work OOB (tho it'll be dependent on whatever postgres.js can be configured to support). [1] https://litdb.dev/customize#type-co…

Correct me if I'm misunderstanding, but this would allow me to register the desired conversion type for a basic postgres type, to and from JavaScript but not for the return value of a specific function or even a specific invocation of a function. PostGIS uses a lot of functions like ST_AsEWKT, ST_AsMVT or ST_AsGeoJSON [1] to marshal data. While ST_AsGeoJSON will always return "text", ideally you'd want an invocation…

Post by nikisweeting » Fri, Dec 06, 2024, 5:54 AM UTC

lerp-io wrote: post #16

plopz wrote: post #10

Earlier quoted context omitted.

My feelings are similar and I cringe every time I see a "typesafe" db interface that doesn't run time validate the data.

typescript people want types on everything cuz it feels good that way.

Post by maxloh » Fri, Dec 06, 2024, 6:18 AM UTC

jeswin wrote: post #41

maxloh wrote: post #39

Earlier quoted context omitted.

That won't be possible without a lot of work. You'll need to tweak the TypeScript compiler to make the parser comprehend exported variables. For example, import { contacts } from "db" const jane = contacts.one(c => c.email === janeEmail) Marco-like magic can be confusing, as we learned from Svelte. Especially when it's half-baked like the one you are suggesting. Another drawback is that you'll need to compile the cod…

> Marco-like magic can be confusing, as we learned from Svelte. Especially when it's half-baked like the one you are suggesting. When I'm giving examples on a forum thread, I try to provide one that's simpler to understand and captures the essence of the argument. I am not making any claims on completeness. > Marco-like magic can be confusing, as we learned from Svelte. Especially when it's half-baked like the one yo…

  const aFunction = arg => arg.a === arg.b
  
  const aFunctionSrc = aFunction.toString()
  console.log(aFunctionSrc) // 'arg => arg.a === arg.b'

  const transformedFunctionSrc = transform(aFunctionSrc)
  const transformedFunction = new Function(transformedFunctionSrc)
  console.log(transformedFunction) // [Function: anonymous]
  
  // Cache the transformed function in a WeakMap
  // WeakMap values are garbage collected when their keys are garbage collected
  const functionMap = new WeakMap()
  functionMap.set(aFunction, transformedFunction)
  console.log(functionMap.get(aFunction)) // [Function: anonymous]