Log in

No account? Create an account
LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Spotting deleted items? [Mar. 10th, 2003|11:04 am]
LiveJournal Client Discussions


I'm currently writing a combination journal system / LJ client within my Infinite Penguins System (in use here).

It acts as a (fairly) fully featured local journal, with obvious similarities to an LJ, but also sends all items to a 'real' LJ when they're posted (and resyncs any updates made through a cron job) through the 'FLAT' interface. 'Friends' and 'Private' privs are mapped to permission groups in the remote journal, allowing people with an account on your site, but not LJ, to see your friends posts if you want them to.

It's written in PHP - it doesn't do multiple journals yet though, so I'm posting this through the web interface.

Anyway - that's what I'm doing, but the point of this post is as follows: *how* do I know when a post has been deleted at LJ? Syncitems returns no mention of the removed post - is that my only clue!??! The docs are blank on this one...

[User Picture]From: benzado
2003-03-10 08:33 am (UTC)
Based on what you have said, my guess is that syncitems simply forgets about deleted posts. The code behind it was recently rewritten. I would suggest you take a look at the server code and see exactly how it works and, if you like, write a patch to support notification of deleted posts.
(Reply) (Thread)
From: idiequietly
2003-03-13 11:09 am (UTC)
hey cool, I've made something similar. It supports multiple journals.. and the layout is template based so you can basically make it look however you want. I like your idea for the mapped permissions.. I wasnt sure how i wanted that to work in my attempts. its still under development...

syncitems returnes a "del" action when a journal entry is deleted. Is that what you are looking for? Anyways.. msg me if you have any more questions.

journal 1
journal 2
(Reply) (Thread)
[User Picture]From: wechsler
2003-03-13 12:20 pm (UTC)
Ah - in the sync_n_action field? I'd been throwing that away as create/update weren't of interest.
Right, I'll go and add that field to the data I store. Thanks.

Strictly, when I said "it doesn't do multiple journals yet though" I meant posting to communities and so on as one username - it *does* store more than one set of logindata, so multiple LJ-users can each post to their own accounts.

I'd not thought about styling - at the moment it just defines in CSS. One more thought for the to-do list, I guess.
(Reply) (Parent) (Thread)
[User Picture]From: wechsler
2003-03-13 12:53 pm (UTC)
Actually, I store more fields than I thought. The following is the result of
"SELECT * FROM `lj_syncitems` WHERE ACTION = 'del'"
id   	  action   	  itemtype   	  itemnum   	  time   	  journal
165  	del  	L  	166  	2002-03-26 02:11:03  	1
191 	del 	L 	192 	2002-04-04 03:53:30 	1
401 	del 	L 	401 	2002-06-26 07:40:24 	1
444 	del 	L 	446 	2002-07-27 06:03:17 	1

(ie all the del calls I've ever seen)

Now I *know* that an itemnum 955 used to exist, but I've got no record of it.
So either I must be missing some syncitems, or none was released for that delete.
Since I gather the lj_syncitems by calling the syncitems mode with lastsync equal to (newest timestamp in lj_syncitems table), I don't think I'm missing out on any...

However, the syncitems mode specifies that it might not return all the items in one go. I assume then that it returns the older ones first off, then progressively newer ones as you do a request with the latest known timestamps?

So is it suffering amnesia, or am I failing to request all the syncitems?
(Reply) (Parent) (Thread)
From: idiequietly
2003-03-13 09:14 pm (UTC)


yah you are right.. it works off of the date that you send it.. everything after that date.. so you want to update your tables in the the order of the items it sends you because.. if you delete a entry that entry number can be over writen.. you dont want to wait until the end to delete your items.
(Reply) (Parent) (Thread)