[WIP] Support for PostgreSQL (and possibly MySQL/MariaDB) #6
Conversation
|
Just FYI I've ported Norm's SQLite backend to ndb and it worked beautifully. The transition was smooth and now we have proper support for NULL values through Option. Can't wait to migrate PostgreSQL and see ndb officially replace db_* modules. |
|
|
||
| This doc is written with the presumption that the notes marked here are implemented rather than how things work right now. | ||
|
|
||
| * Adding a `isNull` function. (and possibly `isNotNull`) |
There was a problem hiding this comment.
I think NULL-able values are better expressed using Option type (so isNone can be used).
| This doc is written with the presumption that the notes marked here are implemented rather than how things work right now. | ||
|
|
||
| * Adding a `isNull` function. (and possibly `isNotNull`) | ||
| * We deprecate the `sql` string distinction as it seems to do nothing more than add complexity. However, for legacy purposes, the sql type is not removed. |
|
|
||
| * Adding a `isNull` function. (and possibly `isNotNull`) | ||
| * We deprecate the `sql` string distinction as it seems to do nothing more than add complexity. However, for legacy purposes, the sql type is not removed. | ||
| * db_common is made part of the library in preparation of movement of `ndb` to the standard library. As such: |
There was a problem hiding this comment.
- db_common is made part of the library in preparation of movement of
ndbto the standard library. As such:
- embrace the "kinds" from db_common (do the migration)
Sounds reasonable.
Also, (if everything goes well) ndb will not become a part of the standard library, it will be referred in docs, and the standard db_* modules will be moved to the graveyard.
nim-lang/Nim#9453 (comment)
| * db_common is made part of the library in preparation of movement of `ndb` to the standard library. As such: | ||
| - embrace the "kinds" from db_common (do the migration) | ||
| - All of the variants will uniquely interpret all of the types. If a type is specifically not supported, a compile-time error (rather than run-time) is generated. However, I don't think this will ever be needed. If nothing else, a type can be a string conversion. | ||
| - nim can't do decimals. As such, make sure that `DECIMAL` columns can be exported as strings to avoid the faulty `float` conversion. |
| - embrace the "kinds" from db_common (do the migration) | ||
| - All of the variants will uniquely interpret all of the types. If a type is specifically not supported, a compile-time error (rather than run-time) is generated. However, I don't think this will ever be needed. If nothing else, a type can be a string conversion. | ||
| - nim can't do decimals. As such, make sure that `DECIMAL` columns can be exported as strings to avoid the faulty `float` conversion. | ||
| * Add ref links to each introduction to a new function or type. |
There was a problem hiding this comment.
I do not fully understand what it is about.
| * We deprecate the `sql` string distinction as it seems to do nothing more than add complexity. However, for legacy purposes, the sql type is not removed. | ||
| * db_common is made part of the library in preparation of movement of `ndb` to the standard library. As such: | ||
| - embrace the "kinds" from db_common (do the migration) | ||
| - All of the variants will uniquely interpret all of the types. If a type is specifically not supported, a compile-time error (rather than run-time) is generated. However, I don't think this will ever be needed. If nothing else, a type can be a string conversion. |
There was a problem hiding this comment.
I'll reply to #5 (comment) since it covers the same thing.
| """, "green bean", 100, 0.92) | ||
| ``` | ||
|
|
||
| If an error is found during the insertion, the returned number is -1. If you are wanting to do your own error catching, then use the alternate `insertID` function. See [CATCHING ERRORS] . |
There was a problem hiding this comment.
I would rather see it's the other way around.
insertID is the default that leverages nim's exceptions, and tryInsertID should be used for custom error handling in a case when exceptions are not convenient.
|
The message is deleted now, but someone had asked about progress on this PR. I've been oddly busier than I planned and this project got put on the back burner. However, postgresql support is a key item for Nim and I do want to continue on this project. But, it might be another month before I can start up again. If someone wanted to pick it up and start working on it, feel free to copy my fork. So far, I've only done docs and planning in prep for the code work. |
|
If or when I do start work on it again, I'll also want to add "pooling" support to |
|
Wow. It has been a while since I've picked this up. Sadly, my workload has increased, not decreased. None-the-less, I don't like to leave projects hanging. I'm very happy to see that PostgreSQL has largely been added to ndb! The PR appears to be mostly documentation updates. So, that where I'm offering to continue. The plan:
I'm also a technical writer and publisher, so this should not be too much of a stretch if the community is interested in this. Sound like a good idea? |
This is a work-in-progress PR, so please do not accept it yet.
To get started, I've written a short "how-to" doc as a starting point. I'll probably remove it when nearer to the end of development. I'm mostly using it as a personal reference.
https://github.com/JohnAD/ndb.nim/blob/master/How-To-Use-NDB.md
You might want to start with my notes section at the bottom: https://github.com/JohnAD/ndb.nim/blob/master/How-To-Use-NDB.md#notes-about-this-doc as the doc does make some assumed changes.
Does this doc sound like the "preferred way to use" the ndb library?