1 |
But if any user-side changes are assumed to be separated? |
2 |
|
3 |
I mean if there is a boolean field "user", which is triggered for |
4 |
user-changed tables. |
5 |
|
6 |
Or, to be simpler, i use 2 tables in my example. |
7 |
|
8 |
Lets assume that user wants to change description of dev-lang/php -- |
9 |
so that user has to change "dev-lang/php" in table "user-tree", but |
10 |
leave the same in table "portage-tree" unchanged. |
11 |
|
12 |
Of course, current example would make queries into portage-db more |
13 |
complex than they should be, so more optimized version should be found |
14 |
-- but, anyway, there are ways to make things work. |
15 |
|
16 |
---------------------------------------------------------------------------------------- |
17 |
Imagine that (i take only ebuild files into consideration here): |
18 |
* Portage tree is kept in SQL base, which contains the following fields: |
19 |
** Id |
20 |
** LongName (dev-db/mysql-4.1.14) |
21 |
** Name (dev-db/mysql) |
22 |
** ShortName (mysql) |
23 |
** Slot |
24 |
** Server -- which server or server group contains that ebuild (if |
25 |
same ebuild is in several server, it should be repeated in SQL). If |
26 |
empty, then this ebuild is created by user |
27 |
** ServerStatus -- false if deleted from server (only used if UserInfo |
28 |
is not NULL) |
29 |
** Status -- if false, this row will not be used |
30 |
** Current -- if this ebuild is what should be installed if emerge |
31 |
mysql is written on this system |
32 |
** Description |
33 |
** /.../ -- other fields parsed from ebuild |
34 |
** ServerInfo -- ebuild file from server |
35 |
** UserInfo -- user additions to that file |
36 |
|
37 |
* Dependency tree |
38 |
** Will be updated from prev. table |
39 |
|
40 |
Now, updates in server should be in the following form: |
41 |
* Id |
42 |
* ServerInfo |
43 |
* Action -- add/delete/update |
44 |
|
45 |
All other fields will be parsed out from "Action" in user's computer. |
46 |
|
47 |
Any changes to portage tree will be then done via portage commands, |
48 |
not directly to SQL. |
49 |
|
50 |
2006/3/15, Brian Harring <ferringb@×××××.com>: |
51 |
> On Tue, Mar 14, 2006 at 03:50:18PM +0200, tvali wrote: |
52 |
> > Another question now is about sync. |
53 |
> > |
54 |
> > I did read somewhere, that this is not good user behavior to sync more |
55 |
> > than once per day. I understand that as if this is a huge download |
56 |
> > even if there is nothing changed. |
57 |
> > |
58 |
> > Isnt it nice idea to have this database just optimized? |
59 |
> > |
60 |
> > I mean (assuming portage using SQL now) -- that would be really simple |
61 |
> > to log every change in portage tree as series of SQL queries, which |
62 |
> > would reproduce this change. |
63 |
> |
64 |
> Pushing the delta (what you're suggesting) is only usable if it can be |
65 |
> guranteed the user hasn't modified their tree at all (thus resulting |
66 |
> in cache db differing from upstreams). |
67 |
> |
68 |
> That right there is the brass tacks of it; You wouldn't be able to |
69 |
> push just the changes, you would have to regenerate the _whole_ db |
70 |
> (slow, >20k inserts assuming only one table). |
71 |
> |
72 |
> Sidenote... please post seperate threads for seperate |
73 |
> ideas/discussions, else it's damn hard to look back and pull the |
74 |
> specific thread were something was discussed. |
75 |
> ~harring |
76 |
> |
77 |
> |
78 |
> |
79 |
> |
80 |
|
81 |
|
82 |
-- |
83 |
tvali |
84 |
(e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
85 |
icq: "317-492-912") |
86 |
|
87 |
Ühe eesti internetifirma lehel kohtasin tsitaati: |
88 |
If you don't do it excellently, dont do it at all. Because if it's not |
89 |
excellent, it won't be profitable or fun, and if you're not in |
90 |
business for fun or profit, what the hell are you doing here? |
91 |
Robert Townsend |
92 |
|
93 |
-- |
94 |
gentoo-portage-dev@g.o mailing list |