Birden fazla veri taban kullanm multi db

Birden Fazla Veri Tabanı Kullanımı¶

Birden fazla veri tabanı kullanmak için öncelikle projemizin settings.py dosyasına
eklemeler yaparak bu veri tabanlarını tanımlamamız gerekiyor örnek olarak aşağıda bir
postgresql ve mysql veri tabanları için settings.py ayarı var birden fazla ve aynı
olmayan tür olmayan veri tabanlarınıda kullanabiliyoruz.

DATABASES = {
    'default': { # varsayılan olarak ayarladığımız ver tabanımız
        'NAME': 'app_data', # veri tabanı ismi
        'ENGINE': 'django.db.backends.postgresql', # veri tabanı türü
        'USER': 'postgres_user', # kullanıcı
        'PASSWORD': 's3krit' # ve şifre bunları yazma amacımızı bende bilmiyorum bilen varsa yoruma yazarsa düzeltme eklerim
    },
    'users': { #sadece kullanıcları kayıt etmek için açmış olduğumuz ( erişme adı users olan user_data isimli )veri tabanı
        'NAME': 'user_data',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'priv4te'
    }
}

Tabiki varsayılan bir veri tabanı kullanmak istemiyorsanız kullanmaya bilirsiniz bunun
için default kısmını boş bırakmalısınız şu şekilde ;

DATABASES = {
    'default': {},
    'users': {
        'NAME': 'user_data',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'superS3cret'
    },
    'customers': {
        'NAME': 'customer_data',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_cust',
        'PASSWORD': 'veryPriv@ate'
    }
}

Veritabanlarınızı Senkronize Etme¶

Veri tabanı senkronizasyonu komutu bir seferde bir veritabanı üzerinde çalışır.
Varsayılan olarak, varsayılan veritabanı üzerinde çalışır, ancak —database seçeneğini
sağlayarak farklı bir veritabanını senkronize etmesini söyleyebilirsiniz. Dolayısıyla,
yukarıdaki ilk örnekteki tüm veritabanlarına tüm modelleri senkronize etmek için
aşağıdakileri gibi yapmanız gerekir.

$ ./manage.py migrate # varsayılan olarak ayarladığınız veri tabanı senkronize olur
$ ./manage.py migrate --database=users # erişme ismi users olan veri tabanı senkronize olur

Bu da bir diğer örnek varsayılanı boş yaptığımız için

$ ./manage.py migrate --database=users
$ ./manage.py migrate --database=customers

Diğer Yönetim Komutlarını Kullanma¶

Veritabanı ile etkileşim kuran diğer çoğu django-admin komutu, taşıdıkça çalışır;
yalnızca bir defada yalnızca bir veritabanında çalışır; kullanılan veritabanı
denetiminde —database kullanılır.

Bu kuralın bir istisnası makemigrations komutudur. Yeni geçişler oluşturmadan önce
varolan taşıma dosyalarıyla \(bunları düzenlemeyle oluşabilecek\) sorunları yakalamak
için veritabanlarındaki geçiş geçmişini doğrular. Varsayılan olarak, yalnızca varsayılan
veritabanını denetler, ancak varsa yönlendiricilerin allow_migrate () yöntemini
inceler.

Otomatik Veritabanı Yönlendirme \( Routing \)¶

Birden çok veritabanını kullanmanın en kolay yolu, bir veritabanı yönlendirme şeması
oluşturmaktır. Varsayılan yönlendirme şeması, nesnelerin orijinal veritabanına
‘yapışkan’ kalmasını sağlar \(yani, foo veritabanından alınan bir nesne aynı veritabanına kaydedilir\). Varsayılan yönlendirme şeması, bir veritabanı
belirtilmemişse, tüm sorgular varsayılan veritabanına geri dönmesini sağlar.

Varsayılan yönlendirme şemasını etkinleştirmek için herhangi bir şey yapmak zorunda
değilsiniz - her Django projesinde ‘kutunun dışında’ sağlanmaktadır. Bununla birlikte,
daha ilginç veritabanı tahsis davranışlarını uygulamak isterseniz, kendi veritabanı
yönlendiricilerinizi tanımlayabilir ve kurabilirsiniz.

Veritabanı Yönlendiricileri¶

Bir veri tabanı Yönlendirici, dört method sağlayan bir sınıftır: Buralar teknik bilgi
çok takılmayın daha aşağıda kodlarla örneklenecektir daha iyi anlarsınız

db_for_read \(model, \*\*hints\)¶

okuma işlemleri için

Model tipli nesneleri okuma işlemleri için kullanılması gereken veritabanını bildirin

Bir veritabanı işlemi, bir veritabanını seçmede yardımcı olabilecek herhangi bir ilave
bilgi sağlayabilirse, hints sözlüğünde sağlanacaktır. Geçerli hints ile ilgili
ayrıntılar aşağıda verilmiştir.

Herhangi bir öneri yoksa None döndürür.

db_for_write \(model, \*\*hints\)¶

yazma işlemleri için

Model modelindeki nesnelerin yazımında kullanılması gereken veritabanını bildirir3

Bir veritabanı işlemi, bir veritabanını seçmede yardımcı olabilecek herhangi bir ilave
bilgi sağlayabilirse, hints sözlüğünde sağlanacaktır. Geçerli ipuçları ile ilgili
ayrıntılar aşağıda verilmiştir.

Herhangi bir öneri yoksa None döndürür.

allow_relation \(obj1, obj2, \*\*hints\)¶

veri tabanındaki nesne arasındaki ilişkiler için

Obj1 ve obj2 arasındaki bir ilişkiye izin verilirse True değerini döndürür,

İlişki önlenmeli ise False döndürür, None ise seçeneği yoktur.

Bu yanlızca bir doğrulama işlemi dir, foreign key ve many to many İki nesne
arasında bir ilişki olup olmadığının belirlenmesi sağlar.

allow_migrate\(db, app_label, model_name=None, \*\*hints\)¶

\( migrate \) taşıma işlemleri için

Geçiş işleminin, takma ad \( db \) veritabanı ile veritabanında çalışmasına izin verilip
verilmeyeceğini belirler. İşlemi çalıştırması gerekiyorsa True, aksi halde çalışmaması
durumunda False veya yönlendiricinin \( router \) fikri yoksa None döndürür.

app_label konumsal argümanı, taşınan \( migrated yapılan \) uygulamanın etiketidir.

modelname çoğu taşıma \( migrations \) işlemi tarafından taşınan modelin
model._meta.model_name \(model_name 'in küçük harfli versiyonu\) değerine ayarlanır .

İpuçlarını \( hints \) kullanmadığı sürece, RunPython ve RunSQL işlemleri için
None değerini döndürür.

ipuçları \( hints \) yönlendiriciye ek bilgi iletmek için bazı işlemler tarafından
kullanılır.

Model_name ayarlı olduğunda, ipuçları normalde ‘model’ anahtarının altındaki model
sınıfını içerir. Tarihsel bir model olabileceğini ve bu nedenle herhangi bir özel
nitelik, yöntem veya yöneticinin olmadığını unutmayın. Sadece _meta’ya güvenmelisin.

Bu yöntem, belirli bir veritabanında bir modelin kullanılabilirliğini belirlemek için de
kullanılabilir.

makemigrations her zaman model değişiklikleri için geçişler oluşturur, ancak
allow_migrate() yanlış döndürürse, db için geçiş işlemi gerçekleştirilirken model_name
için yapılan tüm taşıma işlemleri sessizce atlanır. Zaten geçiş götüren modeller için
allow_migrate() işlevinin değiştirilmesi, yabancı anahtarların, ek tabloların veya
eksik tabloların kopmasına neden olabilir. Makemigrations, geçiş geçmişini
doğruladığında hiçbir uygulamanın geçiş yapmasına izin verilmeyen veritabanlarını atlar.

Yönelticinin tüm bu yöntemleri sunması gerekmez - bir veya daha fazlasını atlayabilir.
Yöntemlerden biri atlanırsa, Django ilgili denetimi yaparken bu yönlendirici
atlayacaktır.

Hints \( İpuçlar\)¶

Veritabanı yönlendiricisi tarafından alınan ipuçları, hangi veritabanının belirli bir
isteği alması gerektiğine karar vermek için kullanılabilir.

Şu anda, sağlanacak tek ipucu, yürütülmekte olan okuma veya yazma işlemi ile ilişkili
bir nesne örneği. Bu kaydedilen örnek olabilir veya çoktan çoklu ilişkide eklenen bir
örnek olabilir. Bazı durumlarda hiçbir örnek ipucu verilmez. Yöneltici bir örnek ipucu
varlığını denetler ve bu ipucunun yönlendirme davranışını değiştirmek için kullanılıp
kullanılmayacağını belirler.

Yönlendiricileri Kullanma¶

Veritabanı yönlendiricileri, DATABASE_ROUTERS ayarı kullanılarak yüklenir
settings.py de ayarlanması gerekir. Bu ayar, her biri ana yönlendirici
(django.db.router) tarafından kullanılmak üzere bir yönlendirici belirterek sınıf
adlarının bir listesini tanımlar.

Ana yönlendirici, veritabanı kullanımını tahsis etmek için Django’nun veritabanı
işlemleri tarafından kullanılır. Bir sorgu hangi veritabanını kullanacağını bilmeye
ihtiyaç duyduğunda, bir model ve bir ipucu \(varsa\) sağlayarak ana yönlendirici
çağırır. Django, daha sonra bir veritabanı önerisi bulunana kadar her yönlendiriciyi
dener. Hiçbir öneri bulunamazsa, ipucu örneğinin geçerli _state.db dosyasını dener. Bir
ipucu örneği sağlanmazsa veya örnek şu anda veritabanı durumuna sahip değilse, ana
yönlendirici varsayılan veritabanını tahsis edecektir.

Settings.py¶

DATABASE_ROUTERS = [] # şeklinde olmalı

Örnek verelim ve bu örneğin veri tabanı ayarları nasıl olacak bakalım;

DATABASES = {
    'default': {}, # varsayılan bir veri tabanı kullanmıyoruz bu yüzden boş
    'auth_db': {
        'NAME': 'auth_db',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'swordfish',
    },
    'primary': {
        'NAME': 'primary',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'spam',
    },
    'replica1': {
        'NAME': 'replica1',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'eggs',
    },
    'replica2': {
        'NAME': 'replica2',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'bacon',
    },
}

Şimdi rota ayarlamamız gerekiyor. İlk önce, auth uygulaması için sorgular gönderilmesini
bilen bir router’ı auth_db için ayarlayacağız.

class AuthRouter(object):
# AuthRouter isminde sadece auth_db kullanma ismini verdiğimiz veri tabanı rauterini ayarlayacağız
# yani sadece auth_db isimli veri tabanı içindir bu
    """
     Tüm veritabanı işlemlerini kontrol eden yönlendirici
     kimlik doğrulama uygulamasının modeldir.
    """
    def db_for_read(self, model, **hints):
        """
        auth_db'ye giden yetkili modelleri (auth models) Okumaya çalışır.
        """
        if model._meta.app_label == 'auth':
            return 'auth_db'
        return None
    def db_for_write(self, model, **hints):
        """
        Attempts to write auth models go to auth_db.
        """
        if model._meta.app_label == 'auth':
            return 'auth_db'
        return None
    def allow_relation(self, obj1, obj2, **hints):
        """
        Yetkilendirme uygulamasındaki bir model dahil edilirse ilişkilere izin ver.
        iki nesne de auth a ait ise ilişkiye izin veriyor
        """
        if obj1._meta.app_label == 'auth' or \
           obj2._meta.app_label == 'auth':
           return True
        return None
    def allow_migrate(self, db, app_label, model_name=None, **hints):
        """
        Auth uygulamasının yalnızca 'auth_db' veritabanında göründüğünden emin olun.
        """
        if app_label == 'auth':
            return db == 'auth_db'
        return None

Ayrıca diğer tüm uygulamaları birincil / çoğaltma yapılandırmasına gönderen bir
yönlendirici istiyoruz ve aşağıdakileri okumak için rasgele bir kopya seçiyor:

import random
class PrimaryReplicaRouter(object):
    def db_for_read(self, model, **hints):
        """
        Okumalar, rasgele seçilen kopyaya gidiyor.
        """
        return random.choice(['replica1', 'replica2'])
    def db_for_write(self, model, **hints):
        """
        Yazmak için daima primary'w gidiyor.
        """
        return 'primary'
    def allow_relation(self, obj1, obj2, **hints):
        """
        Her iki nesne primary/replica havuzunda bulunuyorsa,
        nesneler arasındaki ilişkilere izin verilir.
        """
        db_list = ('primary', 'replica1', 'replica2')
        if obj1._state.db in db_list and obj2._state.db in db_list:
            return True
        return None
    def allow_migrate(self, db, app_label, model_name=None, **hints):
        """
        Tüm auth olmayan modeller bu havuza girer.
        """
        return True

Diğer veri tabanlarını içinde rauter tanımladığımıza göre son olarak, ayarlar dosyasında
aşağıdakileri ekliyebiliriz \(yönlendiricilerin tanımlandığı modüllere / noktalara gerçek Python yolunu değiştirerek\):

DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.PrimaryReplicaRouter']

sınıf isimlerini veriyoruz burası önem li çünkü yanlış girerseniz django sınıf yolunu
bulamaz \(yönlendiricilerin tanımlandığı modüllere / noktalara gerçek Python yolunu değiştirerek\)yazın

Veritabanı El İle Seçme¶

Django, kodunuzda veritabanı kullanımı üzerinde tam kontrol sahibi olmanızı sağlayan bir
API de sağlar. Elle belirlenen bir veritabanı tahsisi, bir yönlendirici tarafından
ayrılan bir veritabanına göre öncelik taşır.

Bir QuerySet İçin Bir Veritabanı El İle Seçme¶

Bunun için using() fonksiyonunu kullancağız, örnek olarak

>>> # bu kod varsayılan olarak ayarladığınız veri tabanından nesne çeker
>>> Author.objects.all()
>>> # ve bu
>>> Author.objects.using('default').all()
>>> # ama bu other olarak ayarlanan veri tabanından veri çeker
>>> Author.objects.using('other').all()

veri tabanlarına yeni veriyi kayıt etmek içinde using() kullanılır örnek

my_object.save(using='legacy_users')
# bu kod aldığı veriyi "legacy_users" adlı veri tabanına kayıt eder

silme işlemi için yine aynı

u = User.objects.using('legacy_users').get(username='fred')
u.delete() # `legacy_users` veri tabanındaki veriyi siler

Birden Fazla Veri Tabanı İçin Admin Arayüzü Ayarı¶

class MultiDBModelAdmin(admin.ModelAdmin):
    # Alternatif veritabanı adı için kullanışlı bir sabit.
    using = 'other' # kullanılacak olan veri tabanı ismi
    def save_model(self, request, obj, form, change):
        # django ya kayıt yapılacak nesne veri tabanının 'other' olduğunu söyler
        obj.save(using=self.using)
    def delete_model(self, request, obj):
        #djangoya silme işlemi için 'other' veri tabanı olduğunu söyler
        obj.delete(using=self.using)
    def get_queryset(self, request):
        #Django'ya 'diğer' veritabanındaki nesneleri aramasını söyler.
        return super(MultiDBModelAdmin, self).get_queryset(request).using(self.using)
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        # Django'ya bir Sorgu kullanarak ForeignKey widget'lerini yerleştirmesini söyler
        # 'other' veri tabanında tabikide
        return super(MultiDBModelAdmin, self).formfield_for_foreignkey(db_field, request, using=self.using, **kwargs)
    def formfield_for_manytomany(self, db_field, request, **kwargs):
        #Django'ya, 'other' veritabanında bir sorgu kullanarak ManyToMany
        # widget'lerini doldurmasını söyle.
        return super(MultiDBModelAdmin, self).formfield_for_manytomany(db_field, request, using=self.using, **kwargs)

class MultiDBTabularInline(admin.TabularInline):
    using = 'other'
    def get_queryset(self, request):
        # Django'ya 'other' veritabanındaki satıriçi nesneleri aramasını söyle.
        return super(MultiDBTabularInline, self).get_queryset(request).using(self.using)
    def formfield_for_foreignkey(self, db_field, request, **kwargs):
        # Django'ya, 'other' veritabanında bir sorgu kullanarak
        # ForeignKey widget'lerini yerleştirmesini söyle.
        return super(MultiDBTabularInline, self).formfield_for_foreignkey(db_field, request, using=self.using, **kwargs)
    def formfield_for_manytomany(self, db_field, request, **kwargs):
        # Django'ya, "other" veritabanında bir sorgu kullanarak
        # ManyToMany widget'lerini doldurmasını söyle.
        return super(MultiDBTabularInline, self).formfield_for_manytomany(db_field, request, using=self.using, **kwargs)

yine admin py de yaptığımız sınıfları register ile yolluyoruz

from django.contrib import admin
# Belirli modellerle kullanmak için multi-db admin nesnelerini özelleştirme
class BookInline(MultiDBTabularInline):
    model = Book
class PublisherAdmin(MultiDBModelAdmin):
    inlines = [BookInline]
admin.site.register(Author, MultiDBModelAdmin)
admin.site.register(Publisher, PublisherAdmin)
othersite = admin.AdminSite('othersite')
othersite.register(Publisher, MultiDBModelAdmin)

Source¶