Cross Posting

Jul 31, 2001 15:41

Title
Allow users to cross post something between journals.

Short, concise description of the idea
Frequently I post things that are of interest to several groups that I'm involved in. For example, next month at dragoncon, in atlanta, I'll be hosting a sleepover night which we'll be watching the first season of Buffy the Vampire Slayer, so it will be of interest ( Read more... )

§ historical, community membership, crossposting, entry management

Leave a comment

stephenbooth_uk July 31 2001, 13:50:15 UTC
Excellent idea!

I commented on the numbers of synonymous communities a couple of days ago ( http://www.livejournal.com/talkread.bml?itemid=7870497 ).

I just had a look at the LJ schema. Currently each entry has a unique ID itemid which is the primary key on the log table (holds data like which journal an entry was posted in, who posted it, when it was posted &c) and on the logtext table.

As I see it (bear in mind that I am an Oracle DBA and don't know how the BML scripts behind LJ work or whether MySQL will suport this so am prepared to be told by those who do know those things that it won't work) the way to implement this would be to allow the clients to specify multiple ownerids and create multiple records with the same itemid in the log table, one for each ownerid. This would violate the primary key constraint so it would have to changed to a composite key, put it on itemid and ownerid would be the most obvious choice, can MySQL handle composite keys? It would also change the one-2-one relationship between log and logtext to a many-2-one (a minor data model change).

It would probably also be a good idea to change the script that generates friends pages to maintain an in memory list of itemids that it checks and rejects items it's already displayed in this run for another community.

If MySQL doesn't support composite keys then there is another work around that comes to mind(basically use a joining table) but that would be a quite significant data model change (changes to the log table and a new table), script changes accross pretty much every script that deals with entries and would probably up the load on the DB and APP servers (due to the more complex queries) so would not be a good idea.

No doubt those who have a more indepth knowledge of BML, LJ and MySQL could come up with something more suitable.

Reply


Leave a comment

Up