Resultset metadata

[EduFrazao]

• Feature to return resultset metadata on the low level API
  to help dynamic applications to analise column declared data types
  that can be "different" from storage datatypes, like datetime or booleans

[ospfranco]

While I get why would one want this, I feel that is still a niche that ppl will do raw queries against the DB. Same as with the file reading parsing, this adds a lot of complexity to the package which I will probably not maintain over the years.

I'll think about it.

[EduFrazao]

While I get why would one want this, I feel that is still a niche that ppl will do raw queries against the DB. Same as with the file reading parsing, this adds a lot of complexity to the package which I will probably not maintain over the years.

I'll think about it.

Sure, I understand. Its more like a proposal, beucase I do a LOT of low level usage on your library and our users do some dynamic query evaluation (and even editing). They inspect declared types to create dynamic specialized INPUT fields, like DatePickers, Checkboxes, etc. Looking only at the data it may not be possible, and sometimes is not possible to query SQLite for table definitions (like when using views or more complex join querys).

I hope that this can help users like JDBC Metadata API does (off course not as huge and detailed :)), but of course, only if you judge its worthy.

[ospfranco]

Let's merge it. With the caveat that the moment it stops working or becomes a hassle I might just take it out

[EduFrazao]

Let's merge it. With the caveat that the moment it stops working or becomes a hassle I might just take it out

Thanks! But count on me to help with the maintenance! Speaking about that, I will do some tests with React 0.68 this weekend, and I will probably work in the next week to make it "turbo modules compliant". Do you have any interest on that?

[ospfranco]

Turbo modules are not ready, so w/e work right now will only be a hassle, not only for the library but for any user trying to integrate it. I've been playing around with them for some weeks and even today, it's still very experimental.

Additionally, this being a database library, will almost never need to be loaded lazily, so the benefit of lazy importing will be almost null in my opinion.

So, no, I don't see any value in adding turbo module support to quick-sqlite

[EduFrazao]

Turbo modules are not ready, so w/e work right now will only be a hassle, not only for the library but for any user trying to integrate it. I've been playing around with them for some weeks and even today, it's still very experimental.

Additionally, this being a database library, will almost never need to be loaded lazily, so the benefit of lazy importing will be almost null in my opinion.

So, no, I don't see any value in adding turbo module support to quick-sqlite

I understand. I I thought that Turbo Modules have become stable with RN 0.68. My mistake so.

[ospfranco]

I got a turbo module + typescript codegen working

https://www.youtube.com/watch?v=J8tS8BD7_XI

In case you are interested, still... it's a complicated convoluted process :P

[EduFrazao]

I got a turbo module + typescript codegen working

https://www.youtube.com/watch?v=J8tS8BD7_XI

In case you are interested, still... it's a complicated convoluted process :P

Thank you very mutch for this documentation. I'm interested. I will watch it slowly :)

[ospfranco]

There is an even better version

https://www.youtube.com/watch?v=U0shm20ClkU&t=281s

More condensed, in one of the streams I do the android bindings :)