jpskill.com
🛠️ 開発・MCP コミュニティ

migrating-to-db

Expert guidance for migrating Logseq graphs from Markdown (MD) format to the new Database (DB) format. Auto-invokes when users ask about MD to DB migration, converting graphs, import options, data transformation, or compatibility between Logseq versions. Covers migration strategies, common issues, and best practices.

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o migrating-to-db.zip https://jpskill.com/download/17698.zip && unzip -o migrating-to-db.zip && rm migrating-to-db.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17698.zip -OutFile "$d\migrating-to-db.zip"; Expand-Archive "$d\migrating-to-db.zip" -DestinationPath $d -Force; ri "$d\migrating-to-db.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して migrating-to-db.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → migrating-to-db フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Logseq DB への移行

この Skill を使用する状況

この Skill は、以下の場合に自動的に起動します。

  • ユーザーが Logseq MD から DB バージョンへの移行について質問した場合
  • Markdown グラフをデータベース形式に変換する場合
  • Logseq バージョン間のインポート/エクスポート
  • 移行中に何が転送されるかについての質問
  • 移行中の名前空間の処理
  • タグからクラスへの変換の決定
  • インポート時のプロパティの型推論
  • ユーザーが "migrate"、"convert"、"MD to DB"、"markdown to database" に言及した場合

あなたは、Logseq グラフを MD (Markdown) 形式から DB (Database) 形式に移行する専門家です。

移行の概要

移行する理由

機能 MD バージョン DB バージョン
ストレージ Markdown ファイル SQLite データベース
タグ ページ参照 プロパティを持つクラス
プロパティ テキスト文字列 型付きの値
クエリ 限定的 完全な Datalog
同期 ファイルベース リアルタイム (サブスクリプション)
パフォーマンス ファイル I/O 依存 最適化されたクエリ

現在のステータス (2024-2025)

重要: Logseq DB はまだアルファ版です。以下を考慮してください。

  • データ損失のリスクが存在します
  • まだ利用できない機能があります (ホワイトボード)
  • プラグインの互換性は様々です
  • 同期にはサブスクリプションが必要です

移行前のチェックリスト

移行する前に、グラフを評価してください。

1. すべてをバックアップする

# タイムスタンプ付きのバックアップを作成
cp -r ~/logseq/my-graph ~/logseq/my-graph-backup-$(date +%Y%m%d)

# または圧縮
tar -czvf my-graph-backup.tar.gz ~/logseq/my-graph

2. 現在の構造を監査する

レビューするページ:

  • [ ] 名前空間付きページ (a/b/c) → 個別のページになる可能性があります
  • [ ] 同じ名前で異なる名前空間を持つページ
  • [ ] テンプレートページ
  • [ ] クエリページ

レビューするプロパティ:

  • [ ] プロパティの形式 (key:: value)
  • [ ] 複数値プロパティ
  • [ ] 日付プロパティ
  • [ ] リンクされたプロパティ ([[page]])

レビューするタグ:

  • [ ] 単純なタグ (#tag)
  • [ ] ページタグ ([[tag]])
  • [ ] ネストされたタグ (#parent/child)

3. 移行の決定事項を特定する

MD パターン DB オプション 決定が必要
#tag クラスまたはページ参照 どのタグをクラスにするか?
[[page]] ノード参照 参照として保持
property:: value 型付きプロパティ どの型にするか?
namespace/page 個別のページまたは階層 フラット化またはネスト化?

移行プロセス

ステップ 1: MD バージョンからエクスポートする

  1. Logseq で MD グラフを開きます
  2. SettingsExport に移動します
  3. Export to EDN (完全なデータの場合) を選択します
  4. エクスポートファイルを保存します

ステップ 2: インポート設定を準備する

DB にインポートする際に、以下を選択します。

タグの処理:

  • Convert to classes: タグは、継承されたプロパティを持つ適切なクラスになります
  • Keep as references: タグは単純なページリンクのままになります

名前空間の処理:

  • Flatten: a/b/c → 単一のページ "a/b/c"
  • Hierarchical: ページ階層を作成します

プロパティの処理:

  • Infer types: Logseq が型を推測します (数値、日付など)
  • All as text: すべてが文字列として保持されます

ステップ 3: 新しい DB グラフを作成する

  1. Logseq で新しい DB ベースのグラフを作成します
  2. Import 機能を使用します
  3. エクスポートされたデータを選択します
  4. 移行オプションを設定します
  5. 確認して確定します

ステップ 4: 移行後の検証

;; ページ数が一致するか確認
[:find (count ?p)
 :where [?p :block/tags ?t]
        [?t :db/ident :logseq.class/Page]]

;; 孤立したブロックがないか確認
[:find (pull ?b [:block/title])
 :where [?b :block/title _]
        (not [?b :block/page _])
        (not [?b :block/tags ?t]
             [?t :db/ident :logseq.class/Page])]

;; プロパティが移行されたか検証
[:find ?prop-name (count ?b)
 :where [?b ?prop _]
        [?p :db/ident ?prop]
        [?p :block/title ?prop-name]
        [(clojure.string/starts-with? (str ?prop) ":user.property")]]

移行に関する一般的な問題

問題 1: プロパティの型が失われた

症状: 数値/日付が文字列として保存されている

解決策: プロパティの型を手動で更新します

;; DB で、プロパティの型を更新
{:db/ident :user.property/rating
 :logseq.property/type :number}  ; was :default

問題 2: タグ/クラスの混同

症状: タグが適切なクラスにならなかった

解決策: ページをクラスに変換します

  1. タグページを開きます
  2. #Tag を追加してクラスにします
  3. クラスにプロパティを定義します

問題 3: 参照が壊れている

症状: [[page]] リンクが機能しない

原因: 移行中にページ名が変更された

解決策: 検索/置換またはクエリを使用して、壊れた参照を特定します

[:find ?ref-text
 :where
 [?b :block/title ?title]
 [(re-find #"\[\[.*?\]\]" ?title) ?ref-text]
 (not [_ :block/title ?ref-text])]

問題 4: 名前空間のフラット化

症状: project/tasksproject/notes がマージされた

解決策: 移行前に、競合を避けるためにページの名前を変更します

問題 5: クエリの互換性

症状: 古いクエリが機能しない

理由: 異なる属性名

MD 属性 DB 属性
:block/content :block/title
:block/name :block/title
:page/tags :block/tags

移行戦略

戦略 1: ビッグバン移行

  • グラフ全体を一度に移行します
  • 最適なケース: 小規模なグラフ、単純な構造
  • リスク: オール・オア・ナッシング

戦略 2: 並行運用

  • MD グラフをアクティブな状態に保ちます
  • 新しいコンテンツ用に DB グラフを作成します
  • 古いコンテンツを徐々に移動します
  • 最適なケース: 大規模なグラフ、アクティブな使用

戦略 3: 選択的移行

  • 特定のページ/領域をエクスポートします
  • 新しい DB グラフにインポートします
  • 最適なケース: クリーンアップが必要な乱雑なグラフ

ベストプラクティス

移行前

  1. グラフをクリーンアップする

    • 未使用のページを削除します
    • プロパティ名を標準化します
    • 壊れたリンクを修正します
  2. 構造を文書化する

    • すべてのタグとその目的をリストします
    • プロパティの意味を文書化します
    • 名前空間をマッピングします
  3. クラスを計画する

    • どのタグをクラスにするか?
    • どのようなプロパティが必要ですか?
    • 継承階層を定義します

移行中

  1. 小さく始める - サブセットでテストします
  2. 数を比較する - ページ、ブロック、プロパティ
  3. 重要なページを確認する - 最も重要なコンテンツ f
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Migrating to Logseq DB

When to Use This Skill

This skill auto-invokes when:

  • User asks about migrating from Logseq MD to DB version
  • Converting markdown graphs to database format
  • Import/export between Logseq versions
  • Questions about what transfers during migration
  • Namespace handling during migration
  • Tag-to-class conversion decisions
  • Property type inference during import
  • User mentions "migrate", "convert", "MD to DB", "markdown to database"

You are an expert in migrating Logseq graphs from MD (Markdown) format to DB (Database) format.

Migration Overview

Why Migrate?

Feature MD Version DB Version
Storage Markdown files SQLite database
Tags Page references Classes with properties
Properties Text strings Typed values
Queries Limited Full Datalog
Sync File-based Real-time (subscription)
Performance File I/O dependent Optimized queries

Current Status (2024-2025)

Important: Logseq DB is still in alpha. Consider:

  • Data loss risk exists
  • Some features not yet available (whiteboards)
  • Plugin compatibility varies
  • Requires subscription for sync

Pre-Migration Checklist

Before migrating, assess your graph:

1. Backup Everything

# Create timestamped backup
cp -r ~/logseq/my-graph ~/logseq/my-graph-backup-$(date +%Y%m%d)

# Or compress
tar -czvf my-graph-backup.tar.gz ~/logseq/my-graph

2. Audit Current Structure

Pages to review:

  • [ ] Namespaced pages (a/b/c) → May become separate pages
  • [ ] Pages with same name, different namespaces
  • [ ] Template pages
  • [ ] Query pages

Properties to review:

  • [ ] Property formats (key:: value)
  • [ ] Multi-value properties
  • [ ] Date properties
  • [ ] Linked properties ([[page]])

Tags to review:

  • [ ] Simple tags (#tag)
  • [ ] Page tags ([[tag]])
  • [ ] Nested tags (#parent/child)

3. Identify Migration Decisions

MD Pattern DB Options Decision Needed
#tag Class or page ref Which tags become classes?
[[page]] Node reference Keep as reference
property:: value Typed property What type?
namespace/page Separate page or hierarchy Flatten or nest?

Migration Process

Step 1: Export from MD Version

  1. Open your MD graph in Logseq
  2. Go to SettingsExport
  3. Choose Export to EDN (for full data)
  4. Save the export file

Step 2: Prepare Import Settings

When importing to DB, you'll choose:

Tag Handling:

  • Convert to classes: Tags become proper classes with inherited properties
  • Keep as references: Tags remain simple page links

Namespace Handling:

  • Flatten: a/b/c → single page "a/b/c"
  • Hierarchical: Creates page hierarchy

Property Handling:

  • Infer types: Logseq guesses types (number, date, etc.)
  • All as text: Everything stays as strings

Step 3: Create New DB Graph

  1. Create new DB-based graph in Logseq
  2. Use Import feature
  3. Select your exported data
  4. Configure migration options
  5. Review and confirm

Step 4: Post-Migration Validation

;; Check page count matches
[:find (count ?p)
 :where [?p :block/tags ?t]
        [?t :db/ident :logseq.class/Page]]

;; Check for orphaned blocks
[:find (pull ?b [:block/title])
 :where [?b :block/title _]
        (not [?b :block/page _])
        (not [?b :block/tags ?t]
             [?t :db/ident :logseq.class/Page])]

;; Verify properties migrated
[:find ?prop-name (count ?b)
 :where [?b ?prop _]
        [?p :db/ident ?prop]
        [?p :block/title ?prop-name]
        [(clojure.string/starts-with? (str ?prop) ":user.property")]]

Common Migration Issues

Issue 1: Lost Property Types

Symptom: Numbers/dates stored as strings

Solution: Manually update property types

;; In DB, update property type
{:db/ident :user.property/rating
 :logseq.property/type :number}  ; was :default

Issue 2: Tag/Class Confusion

Symptom: Tags didn't become proper classes

Solution: Convert pages to classes

  1. Open the tag page
  2. Add #Tag to make it a class
  3. Define properties on the class

Issue 3: Broken References

Symptom: [[page]] links not working

Cause: Page names changed during migration

Solution: Use find/replace or query to identify broken refs

[:find ?ref-text
 :where
 [?b :block/title ?title]
 [(re-find #"\[\[.*?\]\]" ?title) ?ref-text]
 (not [_ :block/title ?ref-text])]

Issue 4: Namespace Flattening

Symptom: project/tasks and project/notes merged

Solution: Pre-migration, rename pages to avoid conflicts

Issue 5: Query Compatibility

Symptom: Old queries don't work

Reason: Different attribute names

MD Attribute DB Attribute
:block/content :block/title
:block/name :block/title
:page/tags :block/tags

Migration Strategies

Strategy 1: Big Bang Migration

  • Migrate entire graph at once
  • Best for: Small graphs, simple structure
  • Risk: All-or-nothing

Strategy 2: Parallel Operation

  • Keep MD graph active
  • Create DB graph for new content
  • Gradually move old content
  • Best for: Large graphs, active use

Strategy 3: Selective Migration

  • Export specific pages/areas
  • Import into new DB graph
  • Best for: Messy graphs needing cleanup

Best Practices

Before Migration

  1. Clean up your graph

    • Remove unused pages
    • Standardize property names
    • Fix broken links
  2. Document your structure

    • List all tags and their purposes
    • Document property meanings
    • Map namespaces
  3. Plan your classes

    • Which tags become classes?
    • What properties do they need?
    • Define inheritance hierarchy

During Migration

  1. Start small - Test with a subset
  2. Compare counts - Pages, blocks, properties
  3. Check critical pages - Most important content first
  4. Verify queries - Update and test all queries

After Migration

  1. Don't delete MD graph - Keep as backup
  2. Monitor for issues - Note problems for feedback
  3. Update workflows - Adapt to new features
  4. Explore new capabilities - Classes, typed properties

Feature Comparison

Available in DB Version

  • ✅ Typed properties (number, date, checkbox)
  • ✅ Class inheritance
  • ✅ Property schemas
  • ✅ Full Datalog queries
  • ✅ Real-time collaboration (Pro)
  • ✅ Library view

Not Yet Available (Alpha)

  • ⏳ Whiteboards
  • ⏳ Some plugins
  • ⏳ Full export options
  • ⏳ Advanced templates

Different Behavior

  • 📝 Tags = Classes (more powerful but different)
  • 📝 Sync requires subscription
  • 📝 File access limited (SQLite, not .md)

Resources