> On Sept. 17, 2012, 12:28 p.m., Sebastian Trueg wrote: > > How about backwards compatibility? Already existing values in Nepomuk for > > example will become unusable. In other words: this is a behavioural change > > which should only happen in a major release, shouldn't it?
Alright. How about I add a backend configuration variable for fake booleans (and default graphs)? About the old data - It'll be migrated in Nepomuk. I have this NepomukCleaner application which I'll eventually merge into master. I can add the migration over there. - Vishesh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106469/#review19061 ----------------------------------------------------------- On Sept. 17, 2012, 9:40 a.m., Vishesh Handa wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/106469/ > ----------------------------------------------------------- > > (Updated Sept. 17, 2012, 9:40 a.m.) > > > Review request for Nepomuk, Soprano and Sebastian Trueg. > > > Description > ------- > > The checking of these fake boolean types seems to almost take as long > as the query execution ( Valgrind stats - Normal sized queries fetching > 1-5 properties ) > > > Diffs > ----- > > backends/virtuoso/odbcqueryresult.cpp a4f2387 > backends/virtuoso/virtuosomodel.cpp 6633208 > backends/virtuoso/virtuosomodel_p.h 456d1ad > backends/virtuoso/virtuosotools.h 5c9942d > backends/virtuoso/virtuosotools.cpp e4a2da5 > > Diff: http://git.reviewboard.kde.org/r/106469/diff/ > > > Testing > ------- > > > Thanks, > > Vishesh Handa > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
