On 06/06/2011 09:24 PM, Vishesh Handa wrote: > /Hello List. Sebastian and I started talking about the current state of > backup sync, and I send him a PDF (attached) of what the current > problems are. I realize that this discussion should be more public, > hence the CC. ( We are also discussing some internal stuff in the DMS )/ > > Hey Sebastian > > On Tue, Jun 7, 2011 at 12:06 AM, Sebastian Trüg <[email protected] > <mailto:[email protected]>> wrote: > > Hi Vishesh, > > let me start at the end: > > 3. ranges: having more than one range is indeed perfectly possible and > adding support should be fairly simple. But would you be ok if we put > that off until 4.8 > > > It's just something that occurred to me, so I brought it up. I'm in no > hurry to fix it. > > > > 2. properties without a domain default to their parent property's domain > or rdfs:Resource if there is no parent property. At least that is what I > always assumed. But I think the former is not implemented. SO that would > have to be fixed. > > > I forgot that all properties would have a domain of rdfs:Resource. I'll > get started on not allowing abstract properties in storeResource.
Do you really need to? After all that check is already in ClassAndPropertyTree::variantListToNodeSet which applies to all methods including storeResources. Ok, now I need to sleep. More tomorrow. Cheers, Sebastian > > > 1. backupsync > * It seems to me although it is less nice and clean than introducing > something like DeletedResource logging the deleted resources in a > compressed file might be the simplest solution. > > > How do we hook this up in time for 4.7? I'm hoping do re-write the > backup system this week, and have a very stable version ready for RC1. ( > Yes, this qualifies as a bug fix. ) > > > * Remember the backup of graphs and their metadata. Actually IMHO for > backup simple dump and restore would be sufficient. > > > Of course. Now it would even be worth the effort. Dump and restore + > some amount of user identification is sufficient. > > > we do not really > need any syncing there. But if you want to keep the design then a very > cool feature would be to allow the user to restore specific resources > (which have been deleted or changed). > > > No. I'm going to keep syncing and backup separate. They'll both depend > on the nepomuksync library. But that could still be added. > > > * If you do backups that depend on another keep in mind that > 1. users might delete them manually (this is a minor point though > since users should simply not do that) > > > The problem with fresh backups are that they are time consuming and > there is no way to avoid it. With incremental backups will mainly be > done for automated backups. I don't think there will be a big problem > with the user deleting the backups. > > > 2. If you delete older backups you might need to merge them into the > newer ones or design the whole thing in a way that removing one backup > file will simply mean that this data can no longer be restored. ie. data > older than N days is lost for real when deleted. > > > I rather not have a system like that. I'm hoping for something like this - > * User creates a backup - A - It's a fresh backup, which would be very > similar to what is being done right now. > * User creates an incremental backup - A is copied - B. And the changes > since A, are merged into B. A remains unaffected. > > * I like the nxx:sameAs approach. But the practical problem with that is > that resources on two systems could have similar URIs although they are > completely different. Sad but true: QUUID is not even close to unique - > for now. > > > I know the uuids are far from unique, that's why I proposed we have > something like - nepomuk:/res/some-identifier/uuid > > What do you think of having some way to identify each system? And do you > have any thoughts on how the two machines which need to be synced will > communicate? > --- > > You haven't made any objections nor have you said - Makes sense, go > ahead. So, I'm going to assume your silence means "Yes! Vishesh, the new > design is exactly what we need, and you're awesome for figuring it out!" :-P > > > > Cheers, > Sebastian > > On 06/02/2011 11:37 AM, Vishesh Handa wrote: > > Hey Sebastian > > > > I've written down about the new backup-sync framework. Please > could you > > read it and give me your comments. I would like to fix backup in time > > for 4.7. > > > > Apart from that, your definition of abstract properties are those > which > > do not have a range. I think we shouldn't allow properties which > have a > > domain as well. If you're okay with it, I'll make the necessary > changes, > > and implement blocking of abstract properties in storeResources. > > > > I was going through your ClassAndPropertyTree, and I noticed that it > > only gives one range and domain. A property could theoretically have > > many ranges and domain. Did you purposely avoid this? Or is it > > something we should take care of? > > > > Thanks > > Vishesh Handa > > > > > -- > Vishesh Handa _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
