Site Update

Well, it looks like the bug with upload counters has reared its ugly head again. sigh I had thought we had beaten that one already. Somehow, though, it keeps finding its way back in. It's also one of those issues that is circumstatial, and recreating it has been neigh impossible, since I don't have the same cookies and such as the people who are having the problems.

I'll just have to keep banging my head against it. We had four reports of it over this past weekend.

Apologies to anyone experiencing this bug.

v4 Update

The migration script has come a long way, and is nearing completion. Why is it taking so long? Well, part of the issue has been the inclusion of the v4 DB development to coincide with the migration script. Much of the original v4 DB design has changed as new issues have made themselves known. Additionally, new and better methods of storing data and dealing with it mean that the data in the old DB has to be changed on-the-fly when being migrated into the new DB. That transformation isn't always straight-forward. Let me give you an example:

Data that is stored for recording what Rating Qualifiers in the old database is stored as a string of characters, each one representing which qualifiers a user has picked. In the new database, they're being stored as a decimal representation of a binary number. Let's say there are four qualifiers. We can represent that as a binary number: 0000. Each digit is either off ('0') or on ('1'). Once we know which bits are on, and which are off, we can translate that into a decimal number. So, say your bits were 0101. That translates to 5. So, all we're storing is '5'. That can easily translate back and forth from binary, which tells us which qualifiers are set and which aren't.

In the old format, we end up with a string like "LND" or "NSO". We have to parse that out, and test for many different characters being present, each representing a qualifier. Much harder to maintain or update the code if qualifiers change, and it requires much more tedious code to translate back and forth between the stored data and what you see on the screen.

So, in the migration script, we have to do all that tedious translation from the string ("DLNSVO") to a binary ("000000") to a decimal ("0"). But, once that translation is done, the hard part for data translation is complete, and we're ready to use the data for the new code. But, much of the data is changing in that fashion from v3 to v4.

Additionally, with v4, the migration script is automatically excluding accounts that are empty (approximately 5000), and are older than 30 days (so you new members don't have to worry if you haven't uploaded artwork very quickly). Likewise, accounts that have been flagged for deletion by user request will be similarly excluded, if your accounts haven't already been manually removed from the system.

So, that's where we stand at the moment. Hope to have more for you soon!

-- BK

Will you be able to get rid of this upload counter bug with v4?

Thanks for the update. I hope you don't have too many troubles finishing up the migration, not just for our sakes, but for your sanity's sake as well.

Considering v4 is a complete re-write of the system, from the ground up, completely new, and with many more years of professional-level programming experience under my belt, yes. This bug will not exist in v4.

The unfortunate part of this is the fact that the v3 code is honestly not as well-written as I had hoped when I first wrote it in 2002, and it isn't very scalable or easily modified. Finding this bug has been like trying to find a needle in a haystack.

Thanks. The fun part of the migration script is the fact that it's actually helping with my sanity. The knowledge that v4 will leave behind all the problems of v3, which have been rather mind-numbing and sanity-sapping, really has been encouraging and uplifting.

-- BK

I'm really looking forward to v4, it's great to hear updates on the progress. I have a question about the migration script excluding empty accounts though. Sorry if the answer is really obvious and I missed it.

For accounts that have no gallery images uploaded and are older than 30 days, does this mean they have to upload something? Or is this only for accounts that are completely untouched? I'm unsure how this will effect users who have currently empty galleries.
Thanks.

It's currently applying to accounts that simply do not have any artwork in them (Visitor accounts are not included in this check) and that are older than 30 days. Any art-uploading member account that has no artwork in it, and that has been in existence for more than 30 days, will be removed from the site during migration.

Currently, there is no distiction being made between "used to have art" and "has never been used." Unfortunately, there are many accounts in which people have decided to move on, and simply deleted their art to remove it, with no intention of coming back. The easiest way to ensure that your account won't vanish if it's empty is to upload just one image, even if it's just a placeholder image.

This is one of those areas where v3 really fell short; there is very little in the way of account flags or the infrastructure behind them to be able to say "do not delete this account for any reason." However, it might not be a difficult task to add a feature into v3 just to allow users to flag their accounts for "do not delete", even though the rest of the site won't ever use that flag (under v3).

Ideas, questions and feedback: always a good thing. Thanks for the question and additional thoughts on making this smoother for everyone.

-- BK