Re: Chat history progress - GSoC 2017

Paulo Lieuthier <[email protected]> Sun, 25 Jun 2017 15:01:15 -0300
Newsgroups	gmane.comp.kde.devel.kopete
Message-ID	<[email protected]>
On 22-06-2017 04:55, Pali Rohár wrote:
> Adding another unique key just increase size of index and therefore any
> operations with index would be slower.
> 
> Composed primary key (from id and subconversation_id) in Conversations
> is mapped 1:1 to table Messages.
> 
> Therefore creating primary key just via "id" and making
> "subconversation_id" as optional has the same result. And it has only
> one primary key. Because one message cannot have two different "id" or
> two different "subconversation_id".

I get you now. Single primary key it will be, and maybe a 'UNIQUE' 
constraint to force unique (entity_identifier, entity_specifier) pairs. 
'entity_specifier' would be what 'subconversation_id' was supposed to do 
before.

>> I'm trying
>> to build a schema that is as agnostic as possible to implementation
>> details. If it's capable of representing conversations with contacts
>> from different accounts and keep sane history, Kopete should find
>> its way to make that useful.
>>
>> The most common use cases I can imagine are opening a chat window and
>> scrolling up and searching for a text in all history. For that I
>> don't think there is need to have a identifier meaningful for
>> Kopete. Please help me if I'm not seeing the obvious here.
>>
>> One use case I can imagine Kopete making use of a identifier is when
>> deleting a message. I'm not sure if Kopete supports it right now.
> 
> No, it does not support it. But there is some jabber XEP which allows
> editing sent messages and for such functionality it is needed to store
> protocol specific identifier.

Good point!

>> 700 bytes looks like a incredibly large limit to me. But I agree
>> strings should not be used as keys. Anyway, we can always hash them
>> if we need.
> 
> This opens another questions... how to handle collisions? which has
> function to use? or which technique? some perfect hashing? Looks like
> hashing just adds another layer of problems.

Yes, I didn't mean it was a good idea, only that it's available.

What's your opinion on the review requests already submitted? Please, 
tell me if there is anything to improve on them so we can get them merged.

Thanks,
Paulo Lieuthier
signature.asc (application/pgp-signature, 833 B)