Back to Details

creating-oracle-to-postgres-migration-bug-report

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Creating Bug Reports for Oracle-to-PostgreSQL Migration

为Oracle到PostgreSQL迁移创建Bug报告

When to Use

使用场景

  • Documenting a defect caused by behavioral differences between Oracle and PostgreSQL
  • Writing or reviewing a bug report for an Oracle-to-PostgreSQL migration project
  • 记录由Oracle与PostgreSQL之间的行为差异导致的缺陷
  • 为Oracle到PostgreSQL迁移项目撰写或审核Bug报告

Bug Report Format

Bug报告格式

Use the template in references/BUG-REPORT-TEMPLATE.md. Each report must include:
  • Status: ✅ RESOLVED, ⛔ UNRESOLVED, or ⏳ IN PROGRESS
  • Component: Affected endpoint, repository, or stored procedure
  • Test: Related automated test names
  • Severity: Low / Medium / High / Critical — based on impact scope
  • Problem: Expected Oracle behavior vs. observed PostgreSQL behavior
  • Scenario: Ordered reproduction steps with seed data, operation, expected result, and actual result
  • Root Cause: The specific Oracle/PostgreSQL behavioral difference causing the defect
  • Solution: Changes made or required, with explicit file paths
  • Validation: Steps to confirm the fix on both databases
使用references/BUG-REPORT-TEMPLATE.md中的模板。每份报告必须包含：
  • 状态：✅ 已解决、⛔ 未解决、或 ⏳ 处理中
  • 组件：受影响的端点、存储库或存储过程
  • 测试：相关自动化测试名称
  • 严重程度：低/中/高/关键 —— 基于影响范围
  • 问题：Oracle的预期行为与PostgreSQL的实际行为对比
  • 场景：包含种子数据、操作步骤、预期结果和实际结果的有序复现步骤
  • 根本原因：导致缺陷的Oracle/PostgreSQL具体行为差异
  • 解决方案：已实施或需要进行的变更，包含明确的文件路径
  • 验证：在两个数据库上确认修复的步骤

Oracle-to-PostgreSQL Guidance

Oracle到PostgreSQL迁移指南

  • Oracle is the source of truth — frame expected behavior from the Oracle baseline
  • Call out data layer nuances explicitly: empty string vs. NULL, type coercion strictness, collation, sequence values, time zones, padding, constraints
  • Client code changes should be avoided unless required for correct behavior; when proposed, document and justify them clearly
  • Oracle为事实基准 —— 基于Oracle的基准来定义预期行为
  • 明确指出数据层的细微差异：空字符串与NULL、类型转换严格性、排序规则、序列值、时区、填充、约束
  • 除非为了保证正确行为必须修改，否则应避免变更客户端代码；若提出修改，需清晰记录并说明理由

Writing Style

写作风格

  • Plain language, short sentences, clear next actions
  • Present or past tense consistently
  • Bullets and numbered lists for steps and validations
  • Minimal SQL excerpts and logs as evidence; omit sensitive data and keep snippets reproducible
  • Stick to existing runtime/language versions; avoid speculative fixes
  • 使用平实语言、短句，明确后续行动
  • 保持时态一致（现在时或过去时）
  • 步骤和验证内容使用项目符号或编号列表
  • 仅保留必要的SQL片段和日志作为证据；省略敏感数据，确保代码片段可复现
  • 遵循现有的运行时/语言版本；避免推测性修复

Filename Convention

文件名规范

Save bug reports as 
BUG_REPORT_<DescriptiveSlug>.md
where 
<DescriptiveSlug>
is a short PascalCase identifier (e.g., 
EmptyStringNullHandling
, 
RefCursorUnwrapFailure
).
Bug报告保存为
BUG_REPORT_<DescriptiveSlug>.md
，其中
<DescriptiveSlug>
为简短的PascalCase标识符（例如：
EmptyStringNullHandling
、
RefCursorUnwrapFailure
）。