[Gelistirici] [Uludag-commits] r20803 - in trunk/staj-projeleri/paket-arama: . search/pathsearch search/templates src

Ahmet Emre Aladağ emre at emrealadag.com
11 Ara 2008 Per 12:30:33 EET


2008/12/11 Eren Türkay <turkay.eren at gmail.com>

> Kodun tamamını incelemedim ancak her depo için neden ayrı bir model
> tanımlanmış anlamadım.
>
> Tüm depolardaki paketler tek bir tabloda tutulup, "repo" gibi bir
> stunda "contrib2008", "pardus2008" tarzı verilerin saklanması daha hoş
> olmaz
> mıydı?


Selam,

Her repo için ayrı bir sqlgenerator betiği çalıştırılıyor. Bu betikler
pardus-2008.sql.bz2, contrib-2008.sql.bz2 gibi arşivler üretiyor. Bu SQL
dosyalarında yapılan şey ise şu, kendi tablonu DROP et, yeniden oluştur,
içeriğine şu bilgileri gir. Yani bir değişiklik durumunda eskiye göre ne
kadar değişti, git onu update et deyip hata riskine girmektense temizden
(DROP/CREATE/INSERT) yapıyor işi.

E, bir tabloyu drop ediyorsak tüm depoları aynı tabloda tutamayız çünkü
contrib-2008 sql'i dump edildiğinde pardus-2008 paketleri göçer.

Ayrıca tablolar oldukça uzun olduğu için ayrı tabloda olması işlemi
hızlandırır diye düşündüm (hash mantığı). Tek tabloda olduğunda hangi
paketin hangi depoda olduğunu tutmak da gerekecekti, bu da fazladan veri
tutmak anlamına geliyor. Yapılan işlemler sistemi zorlayabilecek nitelikte
olduğu için mümkün olduğunca performansı göz önüne aldım.

Ha, eğer denseydi ki "ne öyle yukarıdan Pardus-2008 / Contrib-2008 seçip ona
göre arıyoruz, seçmeden arayalım, o bize söylesin hangi depoda olduğunu",
dediğin yöntem daha güzel olurdu. Diğer alternatif ise şu anki modele yeni
"pardus_2008_package_list" gibi tablolar eklemem, ona göre çift sorgu yapmam
olur ki çok da şık olmaz.
-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20081211/511abf0c/attachment-0002.htm>


Gelistirici mesaj listesiyle ilgili daha fazla bilgi