Earlier quoted context omitted.
I think he's referring to behavior that some software has when it encounters raw UNIX timestamps without TZ information. I recall seeing a change like that in Python's datetime module as of late, so that even if UNIX timestamps are UTC by default, it's more explicit. In the case of my project, the goal is to have UTC-only timestamps/dates, and since the resolution I'm using it for is a calendar day, time zone doesn't…
By definition unix timestamps are UTC. Python's datetime module has a lot of footguns because naive timestamps can represent UTC, local time, or even a non-standard application-specific time. Python's aware timestamps just carry the tzinfo information along with the naive timestamp so that you can get to UTC from the abstract naive timestamp. It's a really overdesigned footgun of Python's datetime module more than an…
Show HN: Bi-directional sync between Postgres and SQLite
61–70 of 107 posts
Re: Show HN: Bi-directional sync between Postgres and SQLite
#62Thank you - it’s great to have an alternative to electric-sql. I actually need a local first, disconnected framework. What many people don’t realize is that even in the US, there are many parts without any network connectivity like our parks and preserves. Rangers still need to make queries in those areas.
Re: Show HN: Bi-directional sync between Postgres and SQLite
#63Re: Show HN: Bi-directional sync between Postgres and SQLite
#64It is amazing how often I sit with crappy or no connectivity, even in today's day and age, and so if it were easier for more apps to be designed to work offline first that would truly be amazing. Exciting development PowerSync team, good luck and Godspeed!
Yeah it's a shocker that even major apps like Apple's Weather aren't local first. Lots of room for improvement.
Re: Show HN: Bi-directional sync between Postgres and SQLite
#65For the To Do app example, let's say two clients start with an empty database and each creates a new todo:
Client A creates [id:1, todo:"Buy milk"]
Client B creates [id:1, todo:"Buy cheese"]
Re: Show HN: Bi-directional sync between Postgres and SQLite
#66Very happy with PowerSync. The docs are detailed and well thought out, and the technology is solid. One can see it builds on a decade of sync experience from the Journey team.
Re: Show HN: Bi-directional sync between Postgres and SQLite
#67Well done on the launch! I have been using PowerSync for several months already ( although our own app hasn't quite reached production yet, due to other reasons). Very happy with PowerSync. The docs are detailed and well thought out, and the technology is solid. One can see it builds on a decade of sync experience from the Journey team.
Re: Show HN: Bi-directional sync between Postgres and SQLite
#68How do you handle primary keys? Wouldn't auto-incrementing integers lead to duplicate keys since clients are not aware of each other? For the To Do app example, let's say two clients start with an empty database and each creates a new todo: Client A creates [id:1, todo:"Buy milk"] Client B creates [id:1, todo:"Buy cheese"]
"PowerSync does not perform any validation that IDs are unique. Duplicate IDs on a client could occur in any of these scenarios:
- A non-unique column is used for the ID.
- Multiple table partitions are used, with the same ID present in different partitions.
- Multiple data queries returning the same record. This is typically not an issue if the queries return the same values (same transformations used in each query)."
Re: Show HN: Bi-directional sync between Postgres and SQLite
#69How do you handle primary keys? Wouldn't auto-incrementing integers lead to duplicate keys since clients are not aware of each other? For the To Do app example, let's say two clients start with an empty database and each creates a new todo: Client A creates [id:1, todo:"Buy milk"] Client B creates [id:1, todo:"Buy cheese"]