Scrambled Listings: Has any merchant affected by this seen their listings fixed yet?

[WADE1 Jya]

According to the JIRA comments, there are some outside of the 14xxxx range now. The first incident on JIRA happened directly after someone converted to DD, although CTL (with no proof) argues it happened before DD started. So my suspicion is DD is causing data redundancy issue (which most likely can't be reversed) caused by conflict between the DD list and the MagicBox list in the database.

I suspect that as more people convert to DD it will get more scrambled (as this is the nature of the problem). The only way it will stop happening is when LL applies appropriate database normalization measures, which they quite likely do not even have an expert on staff to take care of this properly. I am shocked that appropriate measures were not in place already & it makes me worry if all our data (financial info, L$ balance, SL inventory, etc) could be stored in this same dangerous way.

Anyways, continuing to run the marketplace site live while this problem can & will only exacerbate is completely insane, in my opinion. Marketplace should be closed until this is resolved.

[Kenbro Utu]

Maybe someone could test whether my happy "coincidence"  was just that or if flagging my items is what enable me to edit them.  Have someone flag a particular one of your cross listings and see if it enables you to edit it to have correct picture and listing.  

[Marcus Hancroft]

---

WADE1 Jya wrote:

According to the JIRA comments, there are some outside of the 14xxxx range now. The first incident on JIRA happened directly after someone converted to DD, although CTL (with no proof) argues it happened before DD started. So my suspicion is DD is causing data redundancy issue (which most likely can't be reversed) caused by conflict between the DD list and the MagicBox list in the database.

I suspect that as more people convert to DD it will get more scrambled (as this is the nature of the problem). The only way it will stop happening is when LL applies appropriate database normalization measures, which they quite likely do not even have an expert on staff to take care of this properly. I am shocked that appropriate measures were not in place already & it makes me worry if all our data (financial info, L$ balance, SL inventory, etc) could be stored in this same dangerous way.

Anyways, continuing to run the marketplace site live while this problem can & will only exacerbate is completely insane, in my opinion. Marketplace should be closed until this is resolved.

---

Ah ok.  If what you suspect is true (and I think it probably is), then starting a new storefront with direct delivery only should not result in any cross-linked listings because there's no magic box in the mix, right?

[Kampu Oyen]

>Ah ok.  If what you suspect is true (and I think it probably is), then starting a new storefront with direct delivery only should not result in any cross-linked listings because there's no magic box in the mix, right?

And now we're even somehow blaming the magic boxes for the 14xxxxx scramble?

Maybe I'll believe that when it's been shown that none of the scrambled listings were between items to which no magic box had been connected at the time of the scramble (yarite).

Really, it just doesn't follow that there's anything about box function that should cause data to be moved either into or out of listing fields such as the photos unless someone worked very very hard to assure this specific effect. 

The scrambling happens at the same time as the DD deployment and impacts people who used Xstreet without impacting people who came to the Marketplace later, and yet, somehow, it's got to be those pesky boxes making all the new trouble?

How convenient for CTL.

 

 

[WADE1 Jya]

---

Kampu Oyen wrote:

someone worked very very hard to assure this specific effect.

---

I agree with everything you said except this little bit^^^

Since CTL invested metric tonnage of effort into DD, CTL may naturally be seen trying to protect the DD agenda while this data corruption issue continues to balloon, but I doubt the cause was intentional sabotage effort.

Its most likely just extremely amateurish database management.

With a bit of research you'll see it is likely a problem caused by bad database design. I see how being on the receiving end of the issue it seems pointedly personal -- like some sort of maverick attack.... that's possible, but I doubt it. Just google 'database redundancy' & 'database normalization' for more info about this standard problem which is symptomatic of bad design.

I am just starting myself to deal with managing extremely large datasets for the creation of my own worlds. As a newbie to the field with no experts on hand (I am unfortunate to be born of small capital & just can't afford to hire them yet) I have already accidentally caused this problem in my own database work. Luckily, I did take some basic precautions, like maintaining a stepped archive of the data's timeline

history

which allowed me to rollback & eliminate the issue. Took me maybe an hour to solve & I learned never to do that again!

The fact that Linden Lab is trying to squash this three weeks later indicates to me that none of even the most elementary precautionary measures were in place, & most likely all corrupted fields are nonrecoverable. That's a frightening level of unprofessionalism for a large company.

Normally all paying customers affected would get compensated for an issue of this magnitude ....or at very least get some honest communication on progress (or lack thereof)... but this is Linden Lab we're talking about.

[Marcus Hancroft]

Mornin, J.

Ya know what...I don't subscribe to the conspiracy theory that somebody at Linden Lab has deliberately sabotaged the marketplace system.  I think Wade has it right and it's purely bad database creation and maintenance.  I see, in my minds eye, little children pounding away at the keyboards in the commerce team office and laughing and giggling all the while.  Okay, maybe they aren't "children" up there, but, they certainly are amateurs. 

Personally, I think the magic boxes were silently failing long before the roll out of direct delivery.  Flea created a thread about that and I think that's correct also.

 

[Kampu Oyen]

A theory of mere incompetence does not explain why the boxes are going to be shut off on 1 June without first providing DD support for breedables.

A theory of intentional service downgrades does.

[WADE1 Jya]

---

Kampu Oyen wrote:

A theory of intentional service downgrades does.

---

We are close to agreement. There is a theoretical reason why this could all be intentional but describing exactly what this reason would be in plain detail would probably get me banned -- especially so if that is in fact what is happening! I'll just say it would be nothing maliciously aimed at us from Lindens. In fact, it would not be about us at all. Its just how things are done in their world of venture capitalism & very sad for all involved (including Lindens) if this is in fact what's happening.

However I don't think things are going quite that bad, not quite yet anyway.

Alternatively, (and I think more likely) is the theory that passively following what is currently very popular (but very flawed) Silicon Valley management strategy such as Zuckerberg's "move fast & break things" does explain all we see.

Works fine if you are designing facebook which is a horribly designed website propped up & heavily funded to survive no matter what because facebook just so happens to be the most effective spying tool on the planet with every spy agency from CIA to Israeli secret police drooling over it, vested in wiretapping & datamining this network, a perfect 'informational space' component to help in achieving 'FULL SPECTRUM DOMINANCE'.

"Move fast & break things" or 'scrum' as Lindens might refer to it as is not so great when you are a tiny company nobody heard of with only 60,000 or less interested users at any given time, developing a platform that doesn't benefit any known elite agenda.

Move fast & break things also leads to unintentional service downgrades for the 'little people' out there trying to use the product. The users aren't the focus anymore under this strategy, as its all just one big careless experiment hoping something really cool happens & profits start pouring out of it like its a magical fountain to please their venture capitalists.