Backend misclassification event bug

[lovecraft68]

This thread is going the way of all the others. Something is wrong but it devolves into arguing while the people responsible sit and laugh because they never have to answer to anything, their bootlicks just jack the thread and that's that.

3...2...1 before we get the first meme or boob joke

 

[Underscore_2]

No, you weren't even close. That was when it was first released, not when the version Literotica is currently running was released.


Then you should STFU and stop being that person.

Your response was anticipated, cos its par for the course .... booooooring

 

[IWroteThis]

Your response was anticipated, cos its par for the course .... booooooring

So, you knew you were spouting bullshit before I called you out on it?

Good to know…

 

[nudeblaqgirl]

So, you knew you were spouting bullshit before I called you out on it?

Good to know…

Who cares, dude.

 

[Kumquatqueen]

As you can see there is no checklist and no reason why the stories that were in pending purgatory and posted live for months were sent back

Yes, there is: it says "This is better suited to our forum: http://forum.literotica.com/"

In between "However, we've found that we cannot post your submission in its current form. The checklist below may help you in re-examining your manuscript." and "Please feel free to re-submit the story after a Volunteer Editor has examined it, or after you've made revisions. You can find a list of Volunteer Editors here." is where you find the list of reasons!

Why on earth a chapter of a previously-published story should be 'better suited to our forum' is beyond me, assuming it's not a corrupted file that looks like less than 750 words, but that is a checklist with one 'reason', even if it's complete bollocks.

Has anyone else ever had that 'reason' for a story being rejected?

 

[IWroteThis]

Who cares, dude.

Well, since you asked, I do.

Willful ignorance and deliberately spreading false information needs to be called out as a warning to those who don't already know truth and might believe the lies.

 

[nudeblaqgirl]

Well, since you asked, I do.

Willful ignorance and deliberately spreading false information needs to be called out as a warning to those who don't already know truth and might believe the lies.

Or you're just a pedantic pissant

 

[IWroteThis]

Or you're just a pedantic pissant

Ah, shooting (at) the messenger. How pathetic, but predictable.

 

[nudeblaqgirl]

Ah, shooting (at) the messenger. How pathetic, but predictable.

 

[millamomud]

Jeez, just get a room already

 

[TheRedChamber]

Yes, there is: it says "This is better suited to our forum: http://forum.literotica.com/"

In between "However, we've found that we cannot post your submission in its current form. The checklist below may help you in re-examining your manuscript." and "Please feel free to re-submit the story after a Volunteer Editor has examined it, or after you've made revisions. You can find a list of Volunteer Editors here." is where you find the list of reasons!

Why on earth a chapter of a previously-published story should be 'better suited to our forum' is beyond me, assuming it's not a corrupted file that looks like less than 750 words, but that is a checklist with one 'reason', even if it's complete bollocks.

Has anyone else ever had that 'reason' for a story being rejected?

That caught my eye as well. It's never happened to me, but I'm pretty sure I've seen it discussed here before. Basically, if someone posts a short, maybe rambling muse on some fetish or other in the How To or Essay sections, it might get kicked for being better suited to a forum post.
Given the titles of SmilingLez's works, I'm guessing this doesn't really apply here and is a mistake.

(Yes I had seen it. Here - https://forum.literotica.com/threads/sigh-my-first-year-on-literotica.1623491/#post-100026923)

 

[cadeauxxx]

So many theories. Let's just face reality.

The only reality here is that the site owners never address these problems, so people are left to speculate and try to guess why it is happening to them.

There are so many threads with so many authors talking about how their stories are stuck in pending hell and yet not a single time has one of the owners came out and addressed it. The silence speaks volumes.

 

[Britva415]

If you think they're still running the same version of MySQL on the same version of Linux on the same physical server that they stood up in the beginning, you should stick to "reading" picture books.

It's the same application, though.

Of course the underlying tech stack is going to receive appropriate upgrades over time, but that doesn't make the custom application any more stable.

If anything, they would make it less stable. Every upgrade of any single tech stack element is likely to introduce bugs into a custom app that runs on that stack.

 

[Britva415]

Has anyone else ever had that 'reason' for a story being rejected?

An already-published one?

I mean, not me, no, but nor have I seen anyone in AH or TS saying it happened to them.

A publishing rejection? Yes, I have seen people saying they tried publishing something which wasn't quite a "story," or wasn't even close to a story, and got this rejection message for that reason.

 

[IWroteThis]

It's the same application, though.

Of course the underlying tech stack is going to receive appropriate upgrades over time, but that doesn't make the custom application any more stable.

If anything, they would make it less stable. Every upgrade of any single tech stack element is likely to introduce bugs into a custom app that runs on that stack.

If you had quoted a different portion of my comment with this reply, I would agree with you. There was even a nice section where I explained that the issue is the custom code base, which you could have quoted instead…

To be clear, my original comment was simply debunking repeated claims that Literotica is still running the same bits it was when they stood it up back in 1998; the most repeated being about needing to upgrade to a modern database.

 

[Britva415]

To be clear, my original comment was simply debunking repeated claims that Literotica is still running the same bits it was when they stood it up back in 1998; the most repeated being about needing to upgrade to a modern database.

I guess it depends what you mean by "bits." Lit IS still running the same application. Upgrades? Some. Bug fixes? Some. A new front end? Okay. I think that's what people are saying. It's certainly what I'm saying. It doesn't seem like it's aligned with what you're saying. Having an upgrade to a modern database under the hood doesn't eliminate bit-rot from a 28 year old application running on it, and it doesn't debunk that it's the same app, patched, re-patched, and un-patched.

It's like the Ship of Theseus - maybe it's a whole new ship and maybe it's not, but the skipper at the helm and the charts he's steering by are the same, and haven't been keeping updated with the shifting shoals and changing currents, and she runs aground in places she didn't used to.

 

[IWroteThis]

I guess it depends what you mean by "bits." Lit IS still running the same application. Upgrades? Some. Bug fixes? Some. A new front end? Okay. I think that's what people are saying. It's certainly what I'm saying. It doesn't seem like it's aligned with what you're saying. Having an upgrade to a modern database under the hood doesn't eliminate bit-rot from a 28 year old application running on it, and it doesn't debunk that it's the same app, patched, re-patched, and un-patched.

It's like the Ship of Theseus - maybe it's a whole new ship and maybe it's not, but the skipper at the helm and the charts he's steering by are the same, and haven't been keeping updated with the shifting shoals and changing currents, and she runs aground in places she didn't used to.

Once again, you're just talking circles around both the original comment and my response.

Sorry, but Lit is not the same application it was back then. Sure, it still has a lot of the same concepts and window dressings, and a lot of the new code was based on the old code, but you can't just change the file extension from .pl to .php and have it magically run in the new environment. Likewise, going from .php to .js doesn't work like that either. The code has to be rewritten in the new language.

In regards to your reference to the Ship of Theseus, you're right about it being the same skipper, but wrong about it being the same charts. In fact, you appear to agree with me, at times, that the problem is the reliability of the updates to those charts.

So, again, yes, the code is the problem. However, the problem isn't that the site is still running the 1998 code, because it's not. It's not even that the new code was based off of the old code rather than redesigning the site from scratch each time. No, again, the problem is that the site has grown beyond the capabilities of the people behind it and that deficit is, in part, manifesting as bugs in the code.

 

[cadeauxxx]

Mine has become unstuck and was approved an hour ago after months of waiting. I sent Laurel and Manu the story ID and explained my problem.

Make sure you send the story ID in your message to them. I'm just so happy and appreciative to have this problem resolved.

 

[TheWritingGroup]

I think it's worth saying: I guarantee that Laurel and Manu don't want real non-AI stories stuck. There's something I have no grasp of happening behind the scenes that they haven't solved yet.

 

[qidniz]

No, the problem is the code base behind the scenes. I'm sure that porting it to a new language/platform multiple times didn't help, but the real issue appears to be the lack of proper testing.

The code base is of secondary importance. It could be poor, but no matter how good it might be, it is necessarily limited to what it has to work with: The data, and how that data is stored. In a word, the databases. Or more accurately, their design. (I have seen cases where loading largish datasets went from upwards of several minutes to under five seconds, not by tweaking the query - as people focusing on the code base would look to do - but by changing the design of the database tables, for a completely different query to begin with.)

The fact that revisions take orders of magnitude longer to vet than brand new material clearly means that Lit's storage strategy does not allow diff-ing. Even things like changing the blurb/tagline or revising the content tagging of a story (zero change of actual content) must go through the same laborious process that new material goes through (and is therefore de-prioritized - and gets consigned to backlog hell), which is absurdly inefficient.

Consider, as well, the reports that published versions can inexplicably differ from what the author submitted. That again points to the storage strategy - what exactly is the site preserving?

A typical story is a few pages long. Load the first page - nominally about 15K of text or about 3500 words - into a browser, and "view page source". What do you find? Well over 300K of crud. Somewhere in that mess, a full-text search will find 'itemprop="articleBody"', which is an attribute of the <div> element that surrounds the story content, as broken HTML and certainly not the form in which the original content was submitted. Further along in the mess is the story content again, this time as the "escaped" text content of a JSON text field named 'pageText', also certainly not the form of the original submission. Either one of these forms could be from actual storage, or both could be transforms of a third cockamamie form (likely, as the site supports multiple original submission formats).

Having boxed themselves into poor storage strategies - that now need muscular scripts to generate (broken) HTML - it is probably not surprising that anything outside a simple submit - vet once - publish workflow creates serious problems, that no amount of code base fiddling can hope to fix.

All is not doom and gloom, though. Changing the database designs could be the solution. But that will probably need a lot of courage.

 

[IWroteThis]

The code base is of secondary importance. It could be poor, but no matter how good it might be, it is necessarily limited to what it has to work with: The data, and how that data is stored. In a word, the databases. Or more accurately, their design. (I have seen cases where loading largish datasets went from upwards of several minutes to under five seconds, not by tweaking the query - as people focusing on the code base would look to do - but by changing the design of the database tables, for a completely different query to begin with.)

So, they didn't tweak the query because they wrote a different one? That would seem to support my statement, not counter it.

The fact that revisions take orders of magnitude longer to vet than brand new material clearly means that Lit's storage strategy does not allow diff-ing. Even things like changing the blurb/tagline or revising the content tagging of a story (zero change of actual content) must go through the same laborious process that new material goes through (and is therefore de-prioritized - and gets consigned to backlog hell), which is absurdly inefficient.

No, it doesn't. It has nothing to do with the storage strategy, but the code. It's pretty obvious the site was not developed with the intention of continually editing published works. Perhaps they have added some automation for that, but it certainly appears to be a more labor intensive process than approving new stories.

Of course, some of us (including Laurel and Manu, no doubt) are old enough to understand the concept of "published is permanent." This idea of continually editing after publication is much newer than Literotica itself is.

Consider, as well, the reports that published versions can inexplicably differ from what the author submitted. That again points to the storage strategy - what exactly is the site preserving?

No, it points to the changes made by the code between the submission box and the web page. We have no way of knowing how much of that is changed between the submission box and the database or the database and the web page, but we know that the changes happen in the code. Just like the chicken you put in the freezer wasn't a turkey when you took it out, whatever you put in the database is exactly what you get out of the database.

A typical story is a few pages long. Load the first page - nominally about 15K of text or about 3500 words - into a browser, and "view page source". What do you find? Well over 300K of crud. Somewhere in that mess, a full-text search will find 'itemprop="articleBody"', which is an attribute of the <div> element that surrounds the story content, as broken HTML and certainly not the form in which the original content was submitted. Further along in the mess is the story content again, this time as the "escaped" text content of a JSON text field named 'pageText', also certainly not the form of the original submission. Either one of these forms could be from actual storage, or both could be transforms of a third cockamamie form (likely, as the site supports multiple original submission formats).

And all of that "crud" is put there by the code. None of that comes from the database spontaneously adding or changing things.

Having boxed themselves into poor storage strategies - that now need muscular scripts to generate (broken) HTML - it is probably not surprising that anything outside a simple submit - vet once - publish workflow creates serious problems, that no amount of code base fiddling can hope to fix.

When Literotica was started, they were probably using HTML 4 or 4.0. The current standard is 5.2. Change is inevitable. Not only does the code need to change, but code to change the data is required as well. It has nothing to do with storage strategies.

All is not doom and gloom, though. Changing the database designs could be the solution. But that will probably need a lot of courage.

You are correct that database design can have an impact on efficiency, but you'll mostly see that during the submission and viewing processes, which do not show any undo time lags. It's not going to have any impact on the time it takes Laurel to review each submission and decide which button to push.

 

[qidniz]

So, they didn't tweak the query because they wrote a different one? That would seem to support my statement, not counter it.

The new query was applied to a different database schema altogether (yes, there was a one-shot conversion involved.). The old schema simply did not allow the desired efficiency. My point was that schemas constrain query possibilities.

Perhaps they have added some automation for that, but it certainly appears to be a more labor intensive process than approving new stories.

My point was that this made no sense. (What are diffs for?) That it's an evident fact nevertheless, then must mean that the blatantly obvious solution is being ignored. A "more labor intensive process" is, sorry to say, downright stupid.

Of course, some of us (including Laurel and Manu, no doubt) are old enough to understand the concept of "published is permanent." This idea of continually editing after publication is much newer than Literotica itself is.

I've been involved in software development off and on since 1983. Editing was around back then. "Continually" is a red herring and straw man. Even so, the phenomenal success of Git suggests that it's basically a solved problem.

whatever you put in the database is exactly what you get out of the database.

True. I was suggesting, inter alia, that what they put in the database seems to make diffs practically impossible (see "more labor intensive process" above.) They might want to rethink the putting in part altogether.

 

[IWroteThis]

My point was that this made no sense. (What are diffs for?) That it's an evident fact nevertheless, then must mean that the blatantly obvious solution is being ignored. A "more labor intensive process" is, sorry to say, downright stupid.

Except, as I pointed out, it does make sense. Also, a more labor intensive process is only stupid if it is more disruptive/costly than writing and debugging the automation for it.

With one programmer, the opportunity cost of any change is high. Keeping up with changing technology and adding features with higher anticipated usage is very likely to have a better ROI than a lower usage feature that can be done manually when necessary. Like so many things, it comes down to the limited manpower that Literotica has to do these kind of things.

They didn't say it quite the same (and I'm too lazy to go look for it), but as somebody stated in another thread, readers want something new, not something old rehashed. Therefore, focusing on the ability to add new content is going to be higher value than the ability to make changes to old content that nobody will notice. Even the much more simple task of allowing writers to delete their own stories is not likely to be a priority, again because the site wants more content, not less.

 

[qidniz]

Except, as I pointed out, it does make sense. Also, a more labor intensive process is only stupid if it is more disruptive/costly than writing and debugging the automation for it.

You're basically saying that a stupid process justifies itself. (Cf. my query example, where the fact that the dataset load took minutes ineluctably meant that it could never be otherwise.) Stupidity has no cure.

With one programmer, the opportunity cost of any change is high

AFAIK, they have a separate dev team. Neither Laurel nor Manu are on it.

readers want something new, not something old rehashed.

Sorry, that doesn't wash. Readers prefer readable to unreadable material. When it was published is irrelevant.

 

[IWroteThis]

You're basically saying that a stupid process justifies itself. (Cf. my query example, where the fact that the dataset load took minutes ineluctably meant that it could never be otherwise.) Stupidity has no cure.

No, I'm saying that a process isn't stupid just because you say it's stupid.

If you have to choose which process to rewrite for better efficiency, what's stupid would be to spend that limited time and effort to increase the efficiency of the one with the lowest expected ROI from that improvement.

AFAIK, they have a separate dev team. Neither Laurel nor Manu are on it.

I'm curious where you heard that.

Sorry, that doesn't wash. Readers prefer readable to unreadable material. When it was published is irrelevant.

Actually, when it was published is very relevant. Edited stories don't get relisted on the new story lists. Even if you advertise it on your bio, most people will never have a clue that the story changed. The only way it's going to generate more attention is if you added more or better tags to it.

Also, most of what gets submitted as edits is not massive rewrites that replace something unreadable with something readable. If the difference is that drastic, they're going to delete the original to get rid off all of the negative feedback. No, it's primarily polishing and minor fixes being submitted as edits.

So, yeah, it does wash.