significantotter
significantotter
Explore posts from servers
KKysely
Created by significantotter on 11/15/2023 in #help
Are JSON Arrays not supported for paramterization in the postgres driver?
Hey! I've been loving kysely so far and doing a ton of awesome code cleanup and refactoring with it. But I just hit a big snag with a seeming inability to use my json array columns for updates. It seems that the parameter parsing doesn't work with JSON. The types seem fine: https://kyse.link/?p=s&i=pc0iBgUrhjXxfAlSEh9i (Note that my actual app has well-defined types instead of the object primitive types used in the example) But then when I run this, I get { severity: 'ERROR', code: '22P02', detail: 'Expected ":", but found "}".', where: 'JSON data, line 1: {"{\"bar\":\"baz\"}"}\n' + "unnamed portal parameter $2 = '...'", file: 'jsonfuncs.c', line: '621', routine: 'json_ereport_error' } The only other question I could find related to this in here had a suggestion to stringify the values. But then it breaks the column interface typing and I have to lie about the type every time I use it. That doesn't seem right to me. One other minor, interesting note. The update with [] works, it only begins to fail if you try to update [{}].
16 replies
KKysely
Created by significantotter on 11/11/2023 in #help
Why is eb inferred as any in this update query?
I'm trying to do an update from values inserted in a CTE. But the update's set operation doesn't seem to properly infer a type for the eb variable in its expression builder. If I change the where clause to an eb callback, it does properly infer the type, which makes me concerned I'm not doing this correctly. Am I doing something wrong? Is this a minor typing bug? Here's the code example: https://kyse.link/?p=s&i=zmq2zEhTRnuYMyHNhhyc
5 replies
KKysely
Created by significantotter on 11/4/2023 in #help
Any thoughts on how to move data migrations from knex to kysely?
I've been working on shifting my code over to kysely, and it's been fantastic so far. However, I'm not entirely sure how to restructure my migrations directory into Kysely while maintaining up/down state without some manual overhead. The documentation has great advice for setting up migrations from scratch, but not as much for moving an existing project to its structure. I plan to collect all existing table data into a new initial migration, so that makes this somewhat easier. But there are still challenges. The way I see it I have 2 options: 1. Put a hacky check in the initial migration to apply its change only if one of my tables is not present. 2. Manually create the kysely migration record in existing databases to note that the initial migration has been run. Neither of these feel satisfying to me. Is one preferred? Is there a general best practice that I'm missing becuase this isn't my area of expertise?
9 replies
KKysely
Created by significantotter on 11/3/2023 in #help
Recipe for generated types + JSON?
Hey all! I'm currently migrating my application from objection to Kanon + Kysely, and I'm having trouble figuring out a good solution for the JSON Data Types. I have zod objects built for all of my JSON, but I'm unsure of how to integrate these types in a clean way. As I see it, my best option is to import each Table's interface into a separate Database file. In that file, for each type that has a json object, omit the existing column type and union in the new column type. Of course, that results in unfortunately ugly type annotations. The other option loses basically all of the benefits of Kanon outside of the first generation. In this method, I stop using the type auto-generation, and simply edit the json values into the schema and manually update the kysely schema whenever I need to update. Lastly, I could do the first method, only instead of omitting and unioning, I could explicitly map out the keys and values referencing the old tables. Are there any easier ways to do this? Has anyone else using Kanon figured out a clean way to manage these additional types?
10 replies
DTDrizzle Team
Created by significantotter on 9/14/2023 in #help
Nesting sqlite drizzle into a deeper location in my ts app, difficulties with src/ vs dist/
Hey! I'm very new to drizzle and trying to set up a very small drizzle instance for a service that reads a whole pile of json files and acts as a simple read-only information store. I got most of the setup to work. I have it at a location
src/
--services/
----this-service/
------drizzle.config.ts
------sqlite.db
------schema.ts
------this-service.db.ts
src/
--services/
----this-service/
------drizzle.config.ts
------sqlite.db
------schema.ts
------this-service.db.ts
I have some the command in my package.json
"migrate:this-service": "cd ./src/services/this-service && drizzle-kit push:sqlite"
"migrate:this-service": "cd ./src/services/this-service && drizzle-kit push:sqlite"
This works, but it appears that once I build, the sqlite isn't copied over to the /dist directory. When I then try to call this-service.db.ts, after instantiating drizzle on sqlite in its directory, it doesn't see any of the proper tables from the schema in the sqlite.db file. Is there a way to make this work? Or do I have to move this all to the root directory? One option would be is if there are importable drizzle kit functions to replicate the CLI options. I didn't see that in the documentation. Is that possible?
13 replies