Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider higher level interface using lists of dicts for each row of data? #6

Open
simonprickett opened this issue Oct 7, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@simonprickett
Copy link
Collaborator

No description provided.

@simonprickett simonprickett added the enhancement New feature or request label Oct 9, 2024
@amotl
Copy link
Member

amotl commented Oct 15, 2024

Hi Simon,

because your issue description lacks additional information, I can only try to extrapolate.

dataset is my favourite higher level database interface for Python. Are you referring to something like this, or do you have different things in mind?

With kind regards,
Andreas.

@simonprickett
Copy link
Collaborator Author

I was thinking something higher level, optional (so you can still just use execute) and light as we don't want to be too clever on microcontrollers that have limited memory etc.

I'll take a look at dataset, I was thinking something like this.

Given a table:

CREATE TABLE some_table (id TEXT, temp DOUBLE PRECISION, humidity DOUBLE PRECISION);

Then something like this:

sensor_reading = {
    "id": "2abcde",
    "temp": 23.2,
    "humidity": 58.7
}

Use something like this to save that dict in the database, the driver assumes the key names in the dict are the column names in the table:

crate.insert("some_table". sensor_reading)

@amotl
Copy link
Member

amotl commented Oct 15, 2024

That sounds good!

Concerning data model design, If that resonates with you to provide an implementation that works beyond a specific DDL, so that the high-level interface you are aiming for can be implemented in a generic way, I'd recommend to have a look how Kotori is doing it, emulating the InfluxDB data model, but also how the CTK MongoDB I/O-, and CTK DynamoDB I/O-subsystems are doing it.

Other than that those are generic variants, they also work around other obstacles quickly discovered with CrateDB. For example, the venerable impossibility to store column names with leading underscores, i.e. _foo is invalid, becomes a non-issue without much ado.

Kotori/InfluxDB

time TIMESTAMP
tags OBJECT(DYNAMIC)
fields OBJECT(DYNAMIC)

MongoDB

oid TEXT
data OBJECT(DYNAMIC)

DynamoDB

pk OBJECT(STRICT)
data OBJECT(DYNAMIC)
aux OBJECT(IGNORED)

@amotl
Copy link
Member

amotl commented Oct 15, 2024

Concerning interface design, looking at it from a developer's perspective, it would be nice if we could pull in your driver without much ado into a downstream package like the Terkin Multi-Protocol Datalogger, roughly like its TelemetryTransportHTTP.

@amotl
Copy link
Member

amotl commented Dec 7, 2024

I was thinking something higher level, optional (so you can still just use execute) and light as we don't want to be too clever on microcontrollers that have limited memory etc.

Records is certainly not suitable for microcontrollers, because it is based on SQLAlchemy, but I am sharing it here, because it still might inspire you designing your own micro database wrapper, and also may spark your interest to use it within other demos. See collapsed section about more information how to use it with CrateDB, and where we demonstrate it.

Demonstrating »Records« with »CrateDB«

FYI

dataset is my favourite higher level database interface for Python.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants