> The history of development of Umit is really very interesting to us > that come in this year, as Guilherme said. > > When I spoke with Luis about the QuickSearch, I gave the option to > upload the data into memory, only for him to know that this option > exists and that can work well. :) > When we need performance and large volume of data, is a good solution. > But isn't our case. ;)
Sure... every opinion counts here. Even if the main idea is subject to failure, we can get inspired and come back with a good one. That's the goal of brainstorming ;-) >> Also, I think that keeping a database with reference to the real xml >> stored in a directory could bring us some issues, eg: user wants to >> make backup, and forget to save the xml files, user made the backup >> with xml and database, but then he failed to deploy the files in their >> respective correct places, dealing with exceptions for each case in >> umit code, etc. I'm not saying that we shouldn't go this way, I'm just >> considering some things that can possibly happen, so we can make a >> brainstorm here and come out with a better solution. > > Good observation, Adriano. This is a situation that often occurs. > The process must be independent of the user. > In that case, we have guarantee that the data will be there. > > When we work with files that need to be loaded and that have important > data, it is good that they're in two places. > Work with files is generally faster than database. One option is to > save the scans in ~/.umit/scans/ as suggested by Guilherme, and also > continue saving in the database. Hum... Then, how will umit decide where to look first? Should it synchronize the directory if he finds that the database is newer? Should it performe the search in database if there is no scans directory? Maybe, this is a good approach from the backup point of view, but maybe not from the simplicity of development point of view. This could be a good idea, but I still confused about how could these bits works with this approach. > For the QuickSearch, I'm still forming my opinion on how best to store > the data. Working with files have more performance, as I said, in > compensation working with the database, we can take their features > already ready, as Adriano said. The decision we make for umitdb here is the decision that will affect the way you do the search, because the whole Umit is supposed to use the same database approach. > What you think about this point? You've made some good points, I'm just concerned about the details of implementing this because it is very likely to become complex. But, we can face it if no one come out with a better idea. Kind Regards, -- Adriano Monteiro Marques http://adriano-marques.blogspot.com http://umit.sourceforge.net [EMAIL PROTECTED] "Don't stay in bed, unless you can make money in bed." - George Burns ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
