Logseq DB sürümü: dosya grafiğinden veri modeline geçiş

[[Beşinci bölümde]] Logseq OG ile DB sürümünün iki ayrı ürün çizgisi olduğunu gördük. Şimdi DB sürümünün neden yalnız yeni bir arayüz olmadığını açalım.

Eski modelde merkez dosyaydı

Dosya grafiğinde temel yapı şuydu:

• pages klasöründeki Markdown dosyaları,
• journals klasöründeki günlük Markdown dosyaları,
• assets klasörü,
• blokların Markdown içinde yaşaması,
• properties ve görev durumlarının metin sözdizimine yaslanması.

Bu modelin en büyük avantajı dosyanın kendisinin görünür olmasıydı. Metin editörüyle açılabilir, Git ile izlenebilir ve başka araçlara taşınabilirdi.

DB sürümü bu çalışma biçimini bire bir korumuyor.

Yeni modelde merkez graph verisi

Resmî DB belgesi, masaüstünde graph verisinin db.sqlite içinde tutulduğunu anlatıyor. Assets klasörü yaşamaya devam ediyor; fakat pages ve journals artık birer Markdown dosya koleksiyonu olarak kanonik kaynak değil.

Bu değişiklik yalnız storage formatı değil.

Ürünün geri kalanını da etkiliyor.

Beş temel değişim

1. Page ve block ortak node modeline yaklaşıyor

DB belgesi, node terimini page veya block için ortak ad olarak tanımlıyor.

İkisi de:

• çift köşeli bağlantıyla referanslanabiliyor,
• properties alabiliyor,
• tag alabiliyor,
• embed edilebiliyor,
• favorite yapılabiliyor,
• linked ve unlinked references gösterebiliyor.

Ayrıntısı [[node modelinde]].

2. Property metin etiketi olmaktan çıkıyor

DB sürümünde properties:

• Text,
• Number,
• Date,
• DateTime,
• Checkbox,
• Url,
• Node

gibi tiplere sahip.

Bir property kullanıldıktan sonra tipi değiştirilemiyor. Bu, şemanın artık daha gerçek bir veri kısıtı olduğu anlamına geliyor.

[[Properties bölümünde]] ayrıntılı.

3. Tag tür gibi davranabiliyor

Tag yalnız filtre etiketi değil.

Tag Properties ile etiketi taşıyan bütün node'lara ortak alanlar aktarılabiliyor. Parent tag ve Extends ile kalıtım kurulabiliyor.

Bu model, başka araçlardaki type, class veya supertag yaklaşımına yaklaşıyor.

[[Tags bölümünde]] bunun sınırlarını kuracağız.

4. Görünümler veri modelinin doğal parçası

View sistemi aynı node kümesini:

• Table,
• List,
• Gallery

olarak gösterebiliyor.

Filtre, group by ve sort gibi işlemler uygulama içinde kalıcı görünüm yapılarına dönüşüyor.

5. Otomasyon yüzeyi genişliyor

DB belgesi aynı veri modelini:

• MCP Server,
• scripting,
• CLI,
• Sync/RTC,
• Publish

ile dış sistemlere açıyor.

Bu yüzden DB sürümünü yalnız not uygulaması güncellemesi olarak okumak eksik.

Dosya grafiği neden hâlâ ayrı?

Resmî değişiklik belgesi birçok eski davranışın DB sürümünde kaldırıldığını veya değiştiğini açıkça listeliyor.

Örneğin:

• kanonik veri artık Markdown klasörü değil,
• eski TODO/LATER anahtar sözcükleri görev modelinin merkezi değil,
• block reference davranışı değişiyor,
• properties typed schema kazanıyor,
• namespaces Library üzerinden yönetilebiliyor.

Bu farklar, geçişi bir klasörü başka yere kopyalamaktan daha ciddi hale getiriyor.

Hemen geçmek gerekir mi?

Hayır.

DB sürümünün yeni yetenekleri şu ihtiyaçlarda güçlü:

• typed metadata istiyorsan,
• tag'leri tür gibi kullanmak istiyorsan,
• views/tables ile veri üzerinde çalışıyorsan,
• MCP/CLI/automation önemliyse,
• gerçek zamanlı ortak çalışma hedefliyorsan.

Dosya grafiğinin güçlü yanı ise hâlâ açık Markdown dosyalarıyla çalışması.

Eğer bilgi sisteminin ana şartı her notun diskte doğrudan okunabilir Markdown olmasıysa, migration kararını sadece yeni özelliklere bakarak verme.

Bu dizide ne yapacağız?

Sonraki bölümler DB sürümünün her ana kavramını ayrı ele alacak:

node → properties → tags → tasks → journals → queries → views → Library → cards/templates/assets → MCP → Sync → Publish → plugins → migration → backup/export → mobile → CLI.

Amaç feature listesi çıkarmak değil.

Her bölümde şu soruyu soracağız:

**Bu yeni veri modeli günlük bilgi sisteminde hangi problemi çözüyor ve hangi yeni bağımlılığı getiriyor?**