moggers

I'm glad to see this thread. I've been mulling over this exact issue of deleted_at code leakage with a naive soft-delete implementation. My immediate thought was to use views, so its nice to see this is not yet another case of me using crack-brain ideas out of inexperience.

What's an appropriate naming convention?

Should I do it universally and put transparent views in front of all my tables so I don't have to refactor my code to point to new views whenever I do suddenly need to put in a model constraint that isn't 1:1 with my data layer? Is a transparent view a no-op in terms of perf? if it matters, this is being done in Postgres

I will probably make my constraints partial over the not-deleted records, particularly for unique constraints used for upserts. Am I about to footgun myself? Is it even necessary with the new uniqueness behavior with NULLs being implemented in postgres? Will my performance characteristics be better one way or the other in particular circumstances? It sounds like if I have a high ratio of deleted to not-deleted records a partial index becomes necessary.

Yes, unfortunately I was in that case where pagination simply wasn't provided by the feed. Push notifications of course wouldn't have worked (if they were even supported, and I don't believe they were), since otherwise I would have just sat there polling the feed itself every 20 minutes like a maniac. It seems like this widespread limitation leads to the reliance on aggregators, and second-hand it seems google playing the disappearing act with their aggregation service was one of contributing factors to (or a symptom of?) the decline of RSS. Certainly I would have been willing to just shrug my shoulders and use it if it was still operating when I ran into my one and only case of wanting to use an RSS feed.

The one time I wanted to use an RSS feed I found I had no (acceptable) way to ensure I didn't miss data. New items could be truncated off the feed after anywhere between 10 minutes and two hours, and the solution to this was supposedly to use a third party service to sit in the middle and act as a buffer. There was no way to provide a timestamp or anything like that and I presume the reason is its meant to be generate 1 & serve M.

I'm sure the driving factor to RSS losing popularity is it just doesn't fit into the modern model of making fat stacks of cash off of content that other people create which you control the publishing of. But it certainly doesn't help that it seems very limited as far as a protocol for retrieving a portable log of activity.

I've found in my own use of rust I want async/nonblocking for two things.

1. Be able to timeout a read of a socket

2. Be able to select over multiple sockets, and read whichever is ready first

Usually a combination of both.

epoll/io_uring(I guess? I only ever did research on epoll) seem like the solution being handed to me on a silver platter, however my understanding is if you want to use either of those you're meant to use async in rust, and that while there are some libraries which provide interfaces for this kind of behavior outside of async, they're usually very ad-hoc and that the community is just very laser focused on async as a language construct. What I don't understand is why does Rust consider it necessary to introduce async, futures, runtimes, an executor, async versions of TcpListeners, Files, etc for this?

Why can't I just have a function in the standard library that takes a slice of std::net::TcpListeners, a timeout, blocks, and then gives me whichever is ready to read, when its ready to read, or nothing if the timeout is reached? Its not like I was going to do anything else on that thread while I wait for a packet to be received, it can happily be parked.

Instead I have to select a runtime, and libraries compatible with the runtime, replace all the TcpListeners from the standard library I'm using with tokio TcpListeners or whatever, deal with API change, and now I have to deal with the "turtles all the way down" problem of async as well.

That's not even to get into the whole nightmare that a lot of really sick libraries which I want to use in a blocking nature, are now only providing async APIs, which means its "async or the highway". I am very much not happy about this situation and I don't know what I can do about it. It seems the only response I ever get is "just use it, its easy" but that is not at all convincing me. I don't want to use it!