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
