But if any user-side changes are assumed to be separated? I mean if there is a boolean field "user", which is triggered for user-changed tables.
Or, to be simpler, i use 2 tables in my example. Lets assume that user wants to change description of dev-lang/php -- so that user has to change "dev-lang/php" in table "user-tree", but leave the same in table "portage-tree" unchanged. Of course, current example would make queries into portage-db more complex than they should be, so more optimized version should be found -- but, anyway, there are ways to make things work. ---------------------------------------------------------------------------------------- Imagine that (i take only ebuild files into consideration here): * Portage tree is kept in SQL base, which contains the following fields: ** Id ** LongName (dev-db/mysql-4.1.14) ** Name (dev-db/mysql) ** ShortName (mysql) ** Slot ** Server -- which server or server group contains that ebuild (if same ebuild is in several server, it should be repeated in SQL). If empty, then this ebuild is created by user ** ServerStatus -- false if deleted from server (only used if UserInfo is not NULL) ** Status -- if false, this row will not be used ** Current -- if this ebuild is what should be installed if emerge mysql is written on this system ** Description ** /.../ -- other fields parsed from ebuild ** ServerInfo -- ebuild file from server ** UserInfo -- user additions to that file * Dependency tree ** Will be updated from prev. table Now, updates in server should be in the following form: * Id * ServerInfo * Action -- add/delete/update All other fields will be parsed out from "Action" in user's computer. Any changes to portage tree will be then done via portage commands, not directly to SQL. 2006/3/15, Brian Harring <[EMAIL PROTECTED]>: > On Tue, Mar 14, 2006 at 03:50:18PM +0200, tvali wrote: > > Another question now is about sync. > > > > I did read somewhere, that this is not good user behavior to sync more > > than once per day. I understand that as if this is a huge download > > even if there is nothing changed. > > > > Isnt it nice idea to have this database just optimized? > > > > I mean (assuming portage using SQL now) -- that would be really simple > > to log every change in portage tree as series of SQL queries, which > > would reproduce this change. > > Pushing the delta (what you're suggesting) is only usable if it can be > guranteed the user hasn't modified their tree at all (thus resulting > in cache db differing from upstreams). > > That right there is the brass tacks of it; You wouldn't be able to > push just the changes, you would have to regenerate the _whole_ db > (slow, >20k inserts assuming only one table). > > Sidenote... please post seperate threads for seperate > ideas/discussions, else it's damn hard to look back and pull the > specific thread were something was discussed. > ~harring > > > > -- tvali (e-mail: "[EMAIL PROTECTED]"; msn: "[EMAIL PROTECTED]"; icq: "317-492-912") Ühe eesti internetifirma lehel kohtasin tsitaati: If you don't do it excellently, dont do it at all. Because if it's not excellent, it won't be profitable or fun, and if you're not in business for fun or profit, what the hell are you doing here? Robert Townsend -- gentoo-portage-dev@gentoo.org mailing list
