Index
> Main > Thingamy latest version.Goto page Previous 1, 2, 3 |
| Author |
|
|
JohnFound 01 Feb 2005, 21:45
decard wrote: So what format of timestamp would be the best? Unix timestamp? It would be easy to send and to compare... Yes, unix timestamp is OK (I like dwords  )
Quote: (because the client computer may have clock not set properly) Sorry, it was stupid.  Visibly I need some sleep.
Also, another mistake was about the field Prev - it will be NULL for the first edition of the article, not for the last. OK, I will think a little bit more about the structure of the database... btw: Keeping the previous editions of the articles only in offline database is one possible good solution - we'll have one big distributed backup on every computer with installed Thingamy client, and the database at the server will stay always small. If something happens with the server, everyone can restore missing articles back. Regards. |
|||
01 Feb 2005, 21:45 |
|
|
decard 02 Feb 2005, 11:23
JohnFound wrote: btw: Keeping the previous editions of the articles only in offline database is one possible good solution - we'll have one big distributed backup on every computer with installed Thingamy client, and the database at the server will stay always small. If something happens with the server, everyone can restore missing articles back. So I just don't have to implement any mechanisms for keeping previous articles, right? |
|||
|
02 Feb 2005, 11:23 |
|
|
JohnFound 02 Feb 2005, 12:14
decard wrote: So I just don't have to implement any mechanisms for keeping previous articles, right? Yes, if we choose this approach. What you think about it? |
|||
|
02 Feb 2005, 12:14 |
|
|
decard 02 Feb 2005, 14:22
There is a important problem with storing old editions like that: if client will have more articles (old editions) in its database than the server, there can be conflict between IDs - article of the server can have the same ID as some edition on local disc. One solution is to create another table for older editions, but this would cause a lot of additional work... Or an old editions could get negative ids (-1, -2, ...)... Or maybe storing old editions isn't necessary at all, and backup of whole database is enough?
And my idea for storing editions in local database: what about a "next" field? This would simplify everything: when you want to find only latest article, you will select "WHERE Next=NULL". If you will be looking for older articles, you will start from the latest one, and so on... |
|||
|
02 Feb 2005, 14:22 |
|
|
JohnFound 02 Feb 2005, 14:42
decard wrote: There is a important problem with storing old editions like that: if client will have more articles (old editions) in its database than the server, there can be conflict between IDs - article of the server can have the same ID as some edition on local disc. It is not actually big problem. I am not very sure for exact solution, but for example I can keep all edition of the same article with the same ArticleID (it is not mandatory to have unique ArticleID - I can use two fields primary key) Quote: Or maybe storing old editions isn't necessary at all, and backup of whole database is enough? Hm, I don't know. At the begining, maybe it is not neccessary, but I am sure, when the articles increase, we'll have to implements something similar, so why not now, while the database structure is not finished. Note, that in principle, changes in database structure for RDBMS after the project is finished is pretty hard problem... Quote: And my idea for storing editions in local database: what about a "next" field? This would simplify everything: when you want to find only latest article, you will select "WHERE Next=NULL". If you will be looking for older articles, you will start from the latest one, and so on... Actually the approach with "Next" will simplify only searching for the latest edition. Extracting the whole list of editions will become very hard. In the same time the field "Prev" is the reverse: searching for whole editions list is relatively easy, while searching for the latest edition needs extracting of whole list... One solution is to handle both "Next" and "Prev", but I am not very convinced to make double-linked lists... Regards. |
|||
|
02 Feb 2005, 14:42 |
|
|
beppe85 02 Feb 2005, 20:24
There's no need for Next or Prev fields, but a requirement for a given edition to have an ID higher than its previous version.
So an article must have a (ArticleID, EditionID) primary key. Code: ; historic of editions SELECT EditionID FROM Edition WHERE ArticleID = :AArticleID ORDER BY EditionID ; select previous edition SELECT EditionID FROM Edition WHERE ArticleID = :AArticleID AND EditionID < :AEditionID ORDER BY EditionID DESC LIMIT 1 ; select successor edition SELECT FIRST 1 EditionID FROM Edition WHERE ArticleID = :AArticleID AND EditionID > :AEditionID ORDER BY EditionID ASC LIMIT 1 _________________ "I assemble, therefore I am" If you got some spare time, visit my blog: http://www.beppe.theblog.com.br/ and sign my guestmap |
|||
|
02 Feb 2005, 20:24 |
|
|
JohnFound 02 Feb 2005, 20:32
beppe85 wrote: There's no need for Next or Prev fields, but a requirement for a given edition to have an ID higher than its previous version. Thanks, beppe85. That is, possibly, one good solution. Actually, if decard provides server assigned timestamp, it can be used as a second field of the primary key. Regards |
|||
|
02 Feb 2005, 20:32 |
|
|
decard 02 Feb 2005, 21:26
OK, so now getarticle.php returns creation date and edition date timestamps (just after authid), and post.php returns ID separated by creation date.
|
|||
|
02 Feb 2005, 21:26 |
|
|
decard 07 Feb 2005, 21:14
I decided that server will also hold old editions of articles - I implemented it like beppe85 suggested, and it works fine. I didn't uploaded it because I still have to do some changes...
Next thing that came to my mind is user registration. Something has to be done, at least to allow moderators. User registration itself is something that I would like to implement (at least as an option). There are several reasons for that: what if user has changed his email? He would just change his profile settings then... It would allow some statistics (how many articles/editions were posted...), and users would be recognised by their logins (nice to see "friend_from_board" instead of "JoeD12@yahoo.com")
What do you (future users of Thingamy  ) think about it? Would you post articles if you had to register? |
|||
|
07 Feb 2005, 21:14 |
|
|
beppe85 07 Feb 2005, 21:54
The only bad thing with user registrations, is one more password to remember...
I think it's acceptable to have to register to post, but just reading should not require it, just as a public message board. I'll register, anyway. _________________ "I assemble, therefore I am" If you got some spare time, visit my blog: http://www.beppe.theblog.com.br/ and sign my guestmap |
|||
|
07 Feb 2005, 21:54 |
|
|
Reverend 07 Feb 2005, 21:56
Quote: What do you (future users of Thingamy Very Happy) think about it? Would you post articles if you had to register? It's my first post concerning the subject of Thingamy. I think it's a brilliant idea. And about registering, unfrotunately I suppose it should be implemented. And it will also make Thingamy more secure against spamers. We could make it like it is on many pages eg. an image with word "password" apppears, and to register user must write the word "password". Such protection will stop automatic spam-machines. And of course I think it's not too much to do while registering, so it's just a few seconds. I guess it is worth implementing it |
|||
|
07 Feb 2005, 21:56 |
|
|
JohnFound 11 Feb 2005, 23:04
decard wrote: I decided that server will also hold old editions of articles - I implemented it like beppe85 suggested, and it works fine. I didn't uploaded it because I still have to do some changes... Decard, please post here the latest state of the on-line engine after the last changes. For example, getlist.php now returns non unique IDs - is it as result of database changes and if so, how we can fix this problem? Maybe getlist.php should return pairs - ID<tab>Edition<cr> Also, getarticle.php should have additional argument about edition. Another problem, not discussed yet: What if the user post some article in wrong category? The administrator will change the category - that is easy. But how the client will determine, that some article have changed category - this is imposible now, because we compare only the articles IDs, but not categoryes... Maybe we have to make data returned by getlist.php even more complex: ID<tab>edition<tab>category<cr> Regards |
|||
|
11 Feb 2005, 23:04 |
|
|
decard 12 Feb 2005, 08:31
I simply forgot about updating getlist.php
 Now it returns only one unique IDs.
My idea is that server won't exchange old editions with client. They will exchange only latest version, updates will be determined by timestamp. So I will make getlist.php return articles in following form: ID<tab>edition timestamp<tab>category ID<crlf> Is it OK to you? |
|||
|
12 Feb 2005, 08:31 |
|
|
JohnFound 12 Feb 2005, 10:52
decard wrote: I simply forgot about updating getlist.php Yes, I think it would be enough. But don't you think EditionID and the timestamp, actually represent the same information. One of them is unnecessary. Regards |
|||
|
12 Feb 2005, 10:52 |
|
|
decard 12 Feb 2005, 12:12
JohnFound wrote: Yes, I think it would be enough. But don't you think EditionID and the timestamp, actually represent the same information. One of them is unnecessary. I didn't mean to send edition ID - it is article ID |
|||
|
12 Feb 2005, 12:12 |
|
|
JohnFound 12 Feb 2005, 12:48
decard wrote: I didn't mean to send edition ID - it is article ID No, I am talking about the server internal database structure. It doesn't concern client in any way. I mean that one of the most important RDB ideas is to not duplicate information in different tables and fields. Regards |
|||
|
12 Feb 2005, 12:48 |
|
|
decard 12 Feb 2005, 14:42
yeah, I get it now
So I will remove editionID...
BTW, John, what is your opinion about user registration? |
|||
|
12 Feb 2005, 14:42 |
|
|
JohnFound 12 Feb 2005, 15:09
decard wrote: BTW, John, what is your opinion about user registration? Well, I think it should be at least optional. The content is more important than the author of this content and if someone want to post valuable articles anonimously - it is OK for me. On the other hand, every protected resource automatically becomes target for hackers. Unprotected resources are not interesting for hackers, so we shouldn't do anything related to security. 
In order to protect resources from spamming, we can implement two features (not depending on registration): 1. Time based protection - every IP can post maximum 1 article within 2 minutes interval. 2. Ban list with IP addresses that are forbiden for posting - for most grave violations. But this all is IMHO, so if the most users think we should implement users registration - I have nothing special against it. We only have to fix the algorithms and protocols for authentication and loging-in/out
Regards |
|||
|
12 Feb 2005, 15:09 |
|
|
r22 14 Feb 2005, 02:20
I'm not a fan of registration but I think a rating system placed on the articles along with a # of posts per IP address system would be a good idea. The rating system, because if many people find the post errored then someone who doesn't know better would see the low rating and take the information in a broader sense.
|
|||
|
14 Feb 2005, 02:20 |
|
| Goto page Previous 1, 2, 3 < Last Thread | Next Thread > |
Forum Rules:
|