Reminds me of an observation that any sufficiently large C / C++ program ends up writing it's own garbage collector
Accidental database programming
121–130 of 310 posts
Re: Accidental database programming
#122How does this compare to using directly an ORM lib that supports browser like TypeORM [0] via SQL.js [1]?
[0] https://typeorm.io/ [1] https://typeorm.io/supported-platforms#browser
Re: Accidental database programming
#123Reminds me of the observation that for a sufficiently complex C program, one starts to build their own garbage collector.
Re: Accidental database programming
#124Earlier quoted context omitted.
First, thanks! > It isn't clear how they manage the subscription to data updates/inserts/deletions - it mentions supporting triggers, but that feels icky to me. Architecture post coming soon. In the meantime, I want to clarify that SQLSync does not use triggers for sync. Instead, I hijack SQLites page storage and added page replication to it. Writes are consolidated through an API I call the "reducer" which allows SQ…
You say things like "X is pretty dumb" and then go on saying stuff I don't understand. Pretty annoying if you ask me. And that's despite me having worked with Cassandra, Kafka, Postgres and a variety of programming languages, DevOps tools, having worked with Vuejs and React.
Could you clarify which of:
- page storage
- reducers
- replaying mutations
- acks
you're unclear on?
Re: Accidental database programming
#125Earlier quoted context omitted.
It solves so many problems and makes it so easy to implement if you go this way. But just like mentioned it is hard to convince people that it is what they actually want. People fall into some grand illusion that everything should be always available but in reality then one person is doing changes at a time and if somehow 2 or more people have to work on something - more often than not they should be talking or commu…
you can only have one person work on the code at a time? that seems, very very obviously dumb
Multiple people can work on the code simultaneously and asynchronously, but conflict resolution must be done synchronously.
Re: Accidental database programming
#126So this person is building meteor.js minimongo, but for sqlite. Awesome!
Re: Accidental database programming
#127Earlier quoted context omitted.
i don't get it, how does that solve the same problem for an interactive website?
If you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments necessary for a re-render (over ajax or websockets)
i thought the whole premise of the article was that you don't want to do that, you want to cache some stuff, and instead of writing the cache stuff (a db) yourself, use a real db in your frontend.
if you wanted to just fetch data from your server, it's not a problem anyway, right? a spa can also just fetch fresh data from a server. the whole point of the frontend cache was optimising ux/latency, e.g. for apps with global users but not globally deployed servers
Re: Accidental database programming
#128How does this compare to using directly an ORM lib that supports browser like TypeORM [0] via SQL.js [1]? [0] https://typeorm.io/ [1] https://typeorm.io/supported-platforms#browser
Good question! You can use a ORM with SQLSync. Currently SQLSync doesn't provide an ORM layer for two reasons:
1. there are many that exist, it's better to integrate
2. it's a prototype so I started with the lowest common denominator which is raw SQL.
SQL.js is an inspiring project in the space and led to official upstream support for compiling SQLite to Wasm. Without these projects SQLSync would have been much more difficult (akin to the original difficulty of SQL.js in the first place). That said, SQLSync is also unique from SQL.js in that it includes a synchronization layer that coordinates with the SQLSync server to provide real time collaboration between users.
Re: Accidental database programming
#129I'm trying to achieve something similar with SignalDB: https://signaldb.js.org/
It uses signals for reactivity and is framework agnostic with a mongodb-like query syntax
Re: Accidental database programming
#130Earlier quoted context omitted.
It solves so many problems and makes it so easy to implement if you go this way. But just like mentioned it is hard to convince people that it is what they actually want. People fall into some grand illusion that everything should be always available but in reality then one person is doing changes at a time and if somehow 2 or more people have to work on something - more often than not they should be talking or commu…
you can only have one person work on the code at a time? that seems, very very obviously dumb
I can change A to B on my own, you can change A to C on your own.
At some point we have to communicate which change is correct.
It does not have to be synchronous and it might be via commit message - but still change alone is not enough for conflict resolution.
If you edit word document and someone then changes something there is no commit message but might be comment on document, email or im.