New CCBill Admin - Discuss

[Greenguy]

That's a lie. I refuse to believe that the programmers could not include the paysite's & affiliates code into the new system.

Hell, here's the solution: if my new "unique" account number is 1234567, then have a database that has ALL my old codes in it. Each time it sees one, like 581222 for Amateur facials, replace it with 1234567.

Problem solved.

[MadCat]

Originally Posted by Greenie

That's a lie. I refuse to believe that the programmers could not include the paysite's & affiliates code into the new system.

Hell, here's the solution: if my new "unique" account number is 1234567, then have a database that has ALL my old codes in it. Each time it sees one, like 581222 for Amateur facials, replace it with 1234567.

Problem solved.

From a programmer: problem solved in about 2 days worth of coding, testing, and a few dry conversion runs.

One way or the other you still need a userid, and a siteid that is being linked to. This means that the hash algorithm is reversible, or you have the hash stored as a key with userid/siteid stored alongside of it.

So... you're basically using the same values internally, just that on the outside it looks different.

I utterly fail to see how redirecting the old codes to the new ones becomes impossible -- you already know how the hash is generated, so go ahead and do it.

So far, all I've seen compares to:

"We're releasing a new shiny system, unfortunately our architects and programmers are fucking idiots who can't figure out how to get the old links redirecting to the new links, but we're going to go ahead with it anyway because well, it's new and shiny".

Good luck with that.

[Toby]

Originally Posted by Greenie

That's a lie. I refuse to believe that the programmers could not include the paysite's & affiliates code into the new system.

Hell, here's the solution: if my new "unique" account number is 1234567, then have a database that has ALL my old codes in it. Each time it sees one, like 581222 for Amateur facials, replace it with 1234567.

Problem solved.

Greenie, I understand that you don't like change, but I really think you're being a little unreasonable about this.

Adding that additional data for every existing affiliate and the corresponding data lookup for every affiliate link processed isn't as simple as you make it sound. There are substantial side effects and consequences. Hence my mentioning "large high volume database remaining online and stable" in my earlier post.

[MadCat]

Originally Posted by Toby

Greenie, I understand that you don't like change, but I really think you're being a little unreasonable about this.

Adding that additional data for every existing affiliate and the corresponding data lookup for every affiliate link processed isn't as simple as you make it sound. There are substantial side effects and consequences. Hence my mentioning "large high volume database remaining online and stable" in my earlier post.

Also to grab this in from your earlier post:

Yes, that would have been an ideal solution, but when you're talking about implenting changes across such a large high volume database while it remains online and stable, there are simply some limitations to what can be done.

There's a reason that in the software development best practices there is such a thing as a "testing environment" -- a set of systems that mimics the production environment that can be used for testing.

Also, the procedure to switch from one db to another db is this:

1: Get new hardware
2: Set up new DB (dbnew)
3: Poke up the new system and point it at dbnew
4: The new system should in fact be able to update both the dbnew and the old db (dbold).
5: Run both db's simultaneously
6: check db's daily for differences
7: fix whatever is causing differences
8: switch over fully

Presto.

There's a ton of methods to do a live transfer between different db's -- high volume or not. If they are doing anywhere near the amount of db transactions I think they're doing they will have a high availability cluster anyway, and the money to get a 2nd cluster set up for the new system.

All it requires is people that know what they're doing.

[Greenguy]

Originally Posted by Greenie

That's a lie...

I'd like to apologize for that comment. I don't think Paul is a liar, I just think he's being lied to by the programmers.

[Agent]

Originally Posted by Greenie

Hell, here's the solution: if my new "unique" account number is 1234567, then have a database that has ALL my old codes in it. Each time it sees one, like 581222 for Amateur facials, replace it with 1234567.

Problem solved.

Agreed. Naughty America changed their codes around a few times. When they moved from their #-based ID system to NATS, they developed a way to translate the old ID to the new encrypted NATS one. Their old linkcodes still track and translate to the new NATS system, to this day.