smnc

> I read that the problem with Limit is that it is applied on the end. Meaning their original query will happily take all available results, sort them and then return the first 9. If normal values for freq are known, a simple WHERE freq > X could have helped.

Well you can't get around that considering that `freq` is the result of aggregation. Therefore you do have to "take all available results". Or you could keep a tally for all users and refresh it periodically.

Tom Waits sued for this reason multiple times [1].

I guess he had a strong case because in all three cases he was (or so he claimed) approached to do a commercial and the advertisers went with a Waits-like surrogate after he declined.

https://en.wikipedia.org/wiki/Tom_Waits#Lawsuits

Ah, I see, you're right.

Well, one solution would involve a log table used to log/lookup the migration status: Anytime the real-time system touches data (eg. deletes the subscription in the source table and has nothing to do in the new table) the event is logged. The backfilling routine uses that data to decide wether its data or the current data is "fresher".

If the old subscription data is never (or for a certain period) deleted but merely marked inactive (eg. with fields "timestamp_end" and "timestamp_modified" updated) then that information can be used during the backfilling to decide on what data is more recent. [edit: I guess this is what haldean is reffering to above by "tombstone records."]

That makes sense, I think. Does it? Elsewhere in the thread i referred to the procedure used as "conceptually relatively simple". Most things are conceptually simple, but always with pitfalls and dark things lurking around the edges.

There's only one datastore. I'm not sure what you mean with "perceived stability", it's about data integrity and preventing data loss during a model reshuffle.

I'd like to hear about alternatives if you've had experience.

In step two both collections/tables are updated. The backfilling routine is hopefully "smart" enough to leave stuff already in the new table alone.

The article refers interchangeably to tables and collections. Reading this[1], it seems they are using MongoDB as their transactional database. If they do, it would be interesting to know at what point did they decide to split the subscriptions data into its own collection. The article just states "As we added new features, this data model became problematic."

Mongo-modelling being a black art of sorts (to me, at least) I'd be more interested in what the tipping point was for them (data size and shape, usage patterns) than the relatively straightforward (conceptually at least, operatinally these things are never to be underestimated) table-doubling approach to changing a data model.

[1] https://stripe.com/blog/announcing-mosql

> The Street also expects Microsoft to formally announce 700 job cuts as part of its previously announced plan to cut 2,850 jobs by June 2017.

Interesting, the linked article calls it an "effort to update skills across the company."

Dynamic SQL is not the problem, you can safely construct queries on runtime in most RDBMS-s, the key thing is to let the DB treat user input as parameters. You can concat strings to create dynamic queries all you want, just don't blindly shove user input in there, construct the query dynamicaly with parameter placeholders and then bind the user-passed input as parameters.

Of course, there's still the matter of those queries not nessarily being syntactically or semantically correct which will only bite you on runtime, but that's a different story.

If you're doing dynamic SQL you either know what you're doing, or don't know that you don't know what you're doing. Although that probably goes for most of things in life.

I'm not sure if current releases of SQL Server include the infamous DeWitt clause (http://stackoverflow.com/questions/12115397/is-it-against-li...).

Perhaps they accentuate the difference via pronunciation or inflection. Otherwise I also fail to spot the difference.

> While it's important that we respect and include those people, it's also true that had a human animator produced the same work, we should see the same response.

Not necessarily. I suppose he might be commenting on how depicting that particular movement in such a way might be a choice taken by a "human animator" to achieve an end goal or to evoke a certain (rational or emotional or a combination of the two) response from the viewer (hopefully in context of a greater goal/story). The default response here would be that the animation sequence in question is something that should serve as input or inspiration to the artist(s) creating the movie/video/artproduct/whatever and unlock some previously untappable source in their imagination.

The question that then arises is "What if the artist is also an AI" (whatever we currently mean when we say "AI"). Does that change anything?

It turned out to be due to Incapsula web accelerator/protector [0]. > Incapsula is a service that secures and accelerates the website you were trying to reach.

It works fine in Firefox/Chrome, I was trying to open it using qutebrowser so maybe it's a problem with QtWebKit? Anyways, my fault for jumping to conclusions (thinking the site was hugged to death).

[0] https://www.incapsula.com/why-am-i-seeing-this-page.html

Blocked by security rules? https://i.imgur.com/l2sOlRw.png

> Is all we care about android? I constantly hear the argument, if we don't do all of this android will do their own thing and then that will be the end. Right now we are all suffering and android barely even using this yet. If Linux will carry on without AMD contributing maybe Linux will carry on ok without bending over backwards for android.

Could someone here fill in the details for the uninitiated? Do the kernel devs feel a pressure for the kernel to stay relevant in the Android world?

We should bump this up to the top.

Also on https://dply.co/help/sshkey there's mention of "pubic" key instead of a public key.