LJ -> DW and the "friends" concept.

[scsi]

So im combing through the code adding a switch to enable 32 bit mode (fun stuff is here: http://bugs.dwscoalition.org/show_bug.cgi?id=1632). Conversion docs are here: http://wiki.dwscoalition.org/notes/Upgrading_an_old_LJ_Installation_to_DW_Codebase

In the process of the whole "friends group" concept, I ran into this little problem that Im pounding my head against the wall to figure out.

So it looks like trust_groups is the same as friendgroup2 table. Same table definitions, looks like a straight import (or is it that simple!).

Whats the DW equivalent of a LJ "friend"? Is there a quick and dirty way to convert friend groups and friends to the DW equivalent or are the DJ users going to have to start with a clean slate of friends and friend groups (then the issue about entries using a certain friend group and what happens to them).

Fun stuff.

Comments

[foxfirefey]

The DW equivalent would be having both access and subscribe. Friends groups would translate directly into access groups. (Reading filters are beta right now, but my guess is that friends groups could also, for convenience, be translated into reading filters too, because people use friend groups for two reasons, access and reading.)

Sorry my explanation isn't quicker and dirtier! But I think someone else can be more help there--I just wanted to let you know that a conversion is possible!

[mark]

I agree.

You can probably get away with renaming the table from friendgroup2 to trust_groups. Creating subscription filters out of them is going to be a little more involved, but could be done.

Update for your reading pleasure!

[scsi]

Renaming friendgroup2 -> trust_groups works.

Since the old LJ code used 32 bits, and we are using only the first 32 bits (out of 64 bits) i tried to just straight copy the groupmask from the old friends table into the wt_edges table. All the friends (appeared) to be present in their respective groups.

Access (i guess bit 0) was turned on for all of my friends, however the subscribe was not.

Now does subscribe (in the 64 bit version) use bit 61? I would just have the 'subscribe' use bit 30, but then we break the API for any outside clients. Is bit 31 (the reserved bit in 32-bit land) used for anything or was that just set aside for "future expansion" back in the day. If we aren't using bit 31 for anything then I guess I can snag it in the name of the subscribe flag.

However this is going to pose a problem for any sites migrating from 32 -> 64 in the future, but a script to move bit 31 -> 61 would be easy to do globally.

*sigh*

[pauamma]

Hmm. One wrinkle is that if the user has a fgroup called "Default view", that group's membership should be the default for the reading filter IMO, not the flist.