Replies: 1 comment 3 replies
-
evil laugh
|
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi all,
So we've been looking at SQLite as a simple way of making our entire tariff database available under an open license. The motivations behind this are broadly that it is a container format that is extremely accessible (requires no ETL work to get started with the data), that we can embed custom view logic in, and that is easily enhancable (using e.g. Datasette).
I've been doing some spike work to understand how feasible this would be from an engineering perspective. The way I've been looking at this so far is to get Django to manage the schema just as it manages our PostgreSQL schema, such that Django will create all of the tables and will keep the SQLite schema up to date when we change our main schema. This makes it easy for us to maintain whilst also allowing downstream users to access our new schema straight away. It would also let us e.g. use querysets to put stuff into SQLite.
So far the issues I'm encountering are with SQLite's limited support for types. Django handles most of this except for where we've used the PostgreSQL-specific
DateRange
field – SQLite has no support for that. Ideally in SQLite land we would just have two separate columns, one for the lower and upper parts of the date range, and then we could call the date functions and also useBETWEEN
syntax on them.From what I've looked at though, turning one field into two columns is not really a thing Django will handle. I've also tried to see if Django would let you declare different fields depending on the database in use – again, not a thing as far as I can see. So I'm a bit stuck as to how we could work around the
DateRange
field – does anyone have any ideas?Beta Was this translation helpful? Give feedback.
All reactions