2

我有一个运行 8.4 的石英数据库并已转换为 9.2。Quartz 有一个作业 job_details 表，存储了序列化的作业数据映射 java 对象。

数据库的导出很顺利，但是当我尝试将 sql 转储文件导入 postgres 时，它正在翻译 unicode。我已经包含了转储文件的摘录以及来自表选择的数据。

很难找到解决这个问题的地方。我一直在网上搜索，但还没有走得很远。在导入转储之前，我尝试将编码设置为 SQL_ASCII，但这似乎也没有解决问题。

我还尝试将转储恢复到 8.4 数据库，并且表数据确实正确显示在 qrtz_job_details 表中。


以下是使用 8.4 版 pg_dump 创建的转储文件中的配置属性

SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = on;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = false;


这是作业转储文件的摘录。

COPY qrtz_job_details (sched_name, job_name, job_group, description, job_class_name, is_durable, is_nonconcurrent, is_update_data, requests_recovery, job_data) FROM stdin; AnalyticsScheduler Fa_ESSN_ISS_Loc_L5_C1_P1_BT&L_FPY_task_Weekly Mon Apr 29 13:05:27 CDT 2013 rscripts \N com.hp.vf.server.scheduler.RExecutionJob f f f f \\254\\355\\000\\005sr\\000\\025org.quartz.JobDataMap\\237\\260\\203\\350\\277\\251\\260\\313\\002\\000\\000xr\\000&org.quartz.utils.StringKeyDirtyFlagMap\\202\\010\\350\\303\\373\\305](\\002\\000\\001Z\\000\\023allowsTransientDataxr\\000\\035org.quartz.utils.DirtyFlagMap\\023\\346.\\255(v\\012\\316\\002\\000\\002Z\\000\\005dirtyL\\000\\003mapt\\000\\017Ljava/util/Map;xp\\001sr\\000\\021java.util.HashMap\\005\\007\\332\\301\\303\\026`\\321\\003\\000\\002F\\000\\012loadFactorI\\000\\011thresholdxp?@\\000\\000\\000\\000\\000\\014w\\010\\000\\000\\000\\020\\000\\000\\000\\002t\\000\\017analyticsTaskIdsr\\000\\016java.lang.Long;\\213\\344\\220\\314


psql -d 石英 -f 6-20-2013_quartz.dump.out

表格中的数据如下所示。在以前的数据库中，我确信它确实看起来像上面的转义 unicode 字符。


AnalyticsScheduler | Fa_ESSN_ISS_Loc_L5_C1_P1_BT&L_FPY_task_Weekly Mon Apr 29 13:05:27 CDT 2013 | rscripts | | com.vf.server.scheduler.RExecutionJob | f | f | f | f | \xaced0005737200156f72672e71756172747a2e4a6f62446174614d61709fb083e8bfa9b0cb020000787200266f72672e71756172747a2e7574696c732e537472696e674b65794469727479466c61674d61708208e8c3fbc55d280200015a0013616c6c6f77735472616e7369656e74446174617872001d6f72672e71756172747a2e7574696c732e4469727479466c61674d617013e62ead28760ace0200025a000564697274794c00036d617074000f4c6a6176612f7574696c2f4d61703b787001737200116a6176612e7574696c2e486173684d61700507dac1c31660d103000246000a6c6f6164466163746f724900097468726573686f6c6478703f4000000000000c7708000000100000000274000f616e616c79746963735461736b49647372000e6a6176612e6c616e672e4c6f6e673b8be490cc8f23df0200014a000576616c7565787200106a6176612e6c616e672e4e756d62657286ac951d0b94e08b02000078700000000000522d16740006696e70757473737200136a6176612e7574696c2e41727261794c6973747881d21d99c7619d03000149000473697a6578700000001a77040000002673720021636f6d2e68702e76662e7365727665722e646f6d61696e2e44617465496e707574ab57d72b765c06400300014c000576616c75657400104c6a6176612f7574696c2f446174653b7872002f636f6d2e68702e766


恢复后的 qrtz_job_details 表的描述如下所示。这是在 Heroku 9.2.4 版本的 postgres 上运行的。

chinshaw=# \c 石英_86

quartz_86=# \d qrtz_job_details;
            Table "public.qrtz_job_details"
      Column       |          Type          | Modifiers 
-------------------+------------------------+-----------
 sched_name        | character varying(120) | not null
 job_name          | character varying(200) | not null
 job_group         | character varying(200) | not null
 description       | character varying(250) | 
 job_class_name    | character varying(250) | not null
 is_durable        | boolean                | not null
 is_nonconcurrent  | boolean                | not null
 is_update_data    | boolean                | not null
 requests_recovery | boolean                | not null
 job_data          | bytea                  | 
Indexes:
    "qrtz_job_details_pkey" PRIMARY KEY, btree (sched_name, job_name, job_group)
    "idx_qrtz_j_grp" btree (sched_name, job_group)
    "idx_qrtz_j_req_recovery" btree (sched_name, requests_recovery)
Referenced by:
    TABLE "qrtz_triggers" CONSTRAINT "qrtz_triggers_sched_name_fkey" FOREIGN KEY (sched_name, job_name, job_group) REFERENCES qrtz_job_details(sched_name, job_name, job_group)


这是部署转储后 Postgres 8.4 数据库上同一个表的描述。我确实检查了，两者没有明显区别。

quartz_86=# \d qrtz_job_details;
            Table "public.qrtz_job_details"
      Column       |          Type          | Modifiers 
-------------------+------------------------+-----------
 sched_name        | character varying(120) | not null
 job_name          | character varying(200) | not null
 job_group         | character varying(200) | not null
 description       | character varying(250) | 
 job_class_name    | character varying(250) | not null
 is_durable        | boolean                | not null
 is_nonconcurrent  | boolean                | not null
 is_update_data    | boolean                | not null
 requests_recovery | boolean                | not null
 job_data          | bytea                  | 
Indexes:
    "qrtz_job_details_pkey" PRIMARY KEY, btree (sched_name, job_name, job_group)
    "idx_qrtz_j_grp" btree (sched_name, job_group)
    "idx_qrtz_j_req_recovery" btree (sched_name, requests_recovery)
Referenced by:
    TABLE "qrtz_triggers" CONSTRAINT "qrtz_triggers_sched_name_fkey" FOREIGN KEY (sched_name, job_name, job_group) REFERENCES qrtz_job_details(sched_name, job_name, job_group)
4

1 回答 1

2

数据存储在bytea字段中，并且（根据发行说明）默认 bytea 输出格式从PostgreSQL 9.0更改escape为。hex

您需要更新的 JDBC 驱动程序才能理解新格式。或者，您可以设置bytea_output为escape恢复旧行为。我建议仅对需要向后兼容设置的用户或数据库执行此操作：

ALTER USER quartz_user SET bytea_output = 'escape';

或者

ALTER DATABASE quartz_db SET bytea_output = 'escape';
于 2013-06-25T23:31:28.693 回答