On Wednesday 17 June 2015 13:08:37 Joshua Joseph wrote: > Pali, > Here is an updated schema, correcting the above: > > > --Groups table: > > CREATE TABLE "groups"( > "group_id" Text NOT NULL , --Unique identifier for the group > "description" Text , -- A human readable description of the group > "subject" Text , -- Topic being discussed. > "group_type" Text -- Type of group (IRC, Skype etc) > ); > > > -- Messages Table > CREATE TABLE "messages"( > "entry_id" Integer Primary Key Autoincrement NOT NULL , --- Date and > time of the message > "timestamp" Text , "message" Text , --The content of the message > in HTML format > "local_contact_name" Text , -- Contact Name (Local) > "remote_contact_name" Text , -- Contact Name (Remote) > "importance" Text , > "group_id" Text , -- If this is a group message, this will hold the > group id. If null, this is not a group message > "protocol" Text , -- Protocol in use > "direction" Text , -- Incoming or Outgoing > "local_id" Text , -- The account being used locally > "remote_id" Text, -- The account being used by the remote party > "jabber_resource" text -- The jabber resource containing this message > ); >
Hi, still I see there couple of problems: 1) Why is group_type needed which just specify protocol? Protocol is already present in messages table. 2) I would prefer to have integer primary key for groups and also referenced it from messages table (instead string). I would expect that some SQL databases could have problems to use "unknown" string type as primary key. 3) jabber_resource column is totally useless... first storage should be protocol independent and second it is resource of what? local contact? remote contact? 4) For me it looks like that some column names are too long (like remote_contact_name) and basically names are not consistent... Like local_id and local_contact_name... Try to "clean-up" names. 5) Have you looked at Kopete::Message class deeply? http://api.kde.org/4.x-api/kdenetwork-apidocs/kopete/libkopete/html/classKopete_1_1Message.html E.g direction can be also internal. Why did you not stored MessageState and MessageType? I do not see discussion about it... 6) How will be handled (future) message editation? For this purpose there is Kopete::Message::id() function which returns unique (I think per chat session) number. 7) I see that you completely removed subject from messages table. But you did not write reason? Protocols do not use it? Or do you think it is not needed? Btw, more often I'm using column with _id suffix as reference/foreign key to other table. But do not know if this is something which others prefer or not too... And for handling problem with jabber resource now I got this idea: What about storing this? * protocol * account * contact * from_id * to_id * from_name * to_name (from|to)_id will be full protcol *dependent* identifier, so jabber can store full JID "user@host/resource" and account can represent your local_id and contact your remote_id. But do not know now... Any idea? Make sense? At least it could be needed to modify it to work with multi user group chat correctly... -- Pali Rohár pali.ro...@gmail.com _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
