惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Stack Overflow Blog
Stack Overflow Blog
量子位
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
美团技术团队
小众软件
小众软件
aimingoo的专栏
aimingoo的专栏
Recent Announcements
Recent Announcements
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Microsoft Security Blog
Microsoft Security Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
酷 壳 – CoolShell
酷 壳 – CoolShell
J
Java Code Geeks
V
V2EX
大猫的无限游戏
大猫的无限游戏
D
DataBreaches.Net
博客园 - Franky
爱范儿
爱范儿
T
Tailwind CSS Blog
A
About on SuperTechFans
Google DeepMind News
Google DeepMind News
博客园_首页
B
Blog RSS Feed
博客园 - 司徒正美
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

博客园 - 三国梦回

oracle中date类型在mybatis中查询时遇到的坑 mitmweb在linux上进行反向代理及浏览器中实时查看请求响应 codex对接智谱coding plan,我发现连cc switch也不用了 windows codex更新失败如何处理 windos上codex沙盒报错问题记录 廉颇老矣,装个EclipseMemoryAnalyzer都能卡一小时 codex windows平台中elevated sandbox机制学习 codex windows平台中unelevated sandbox机制学习 bug排查:nacos做配置管理,给服务返回的配置竟然是错的 windows安装codex desktop和cc-switch,接deepseek v4 flash windows安装ddns-go,上传动态的ipv6到自己的域名 immortalWrt路由器上抓包查看电脑联网如何获取ip 路由器刚刷的immortalWrt系统,我是如何配置ipv6的 路由器刷openwrt之ImmortalWrt过程记录--上 spring cloud项目中,在bootstrap.yml中指定了active的profile,结果不生效 线上服务重启后,从nacos取不到配置了,怎么回事 nginx location没学好,把自己坑了一把 技术问题记录20260125 最近遇到的两个技术问题记录 linux服务器文件上传失败 线上遇到的redis和数据库数据未同步问题、redisson内部实现问题 复杂业务系统线上问题排查过程 nacos中配了一个数字,springboot取回来怎么变了 一个java空指针异常的解决过程 简单记录下最近2个月完成的线上系统迁移工作 centos停服,迁移centos7.3系统到新搭建的openEuler 端口telnet不通排查过程 https证书中的subject alternative name字段作用及如何生成含该字段的证书 linux中如何判断一个rpm是手动安装还是通过yum安装的 对接服务升级后仅支持tls1.2,jdk1.7默认使用tls1.0,导致调用失败
spring boot 项目中oracle datasource设置schema
三国梦回 · 2026-05-08 · via 博客园 - 三国梦回

问题1:spring boot 项目中oracle datasource设置schema

背景

假设有个oracle数据库,有个foo用户(创建用户时就会创建一个默认的与用户名同名的schema:foo,schema就是个名称空间,用来隔离各类数据库对象,如表、序列等),密码11111,项目中对应的yaml配置如下:

spring:
  datasource:
  	url: jdbc:oracle:thin:@1.1.1.1:1521:orcl
    username: foo
    password: 111111
    driver-class-name: oracle.jdbc.OracleDriver
    hikari:
        validationTimeout: 2000
        connectionTimeout: 10000
        keepaliveTime: 180000
        maxLifetime: 600000
        minimumIdle: 3
        maximumPoolSize: 3
        idleTimeout: 600000
        connectionTestQuery: ""

那么上文这种配置,使用foo用户连接数据库,默认就能访问foo这个schema下的表,我们写sql时:

select * from test_table;
其实就相当于访问:
select * from foo.test_table;

但如果我们换个用户bar登录:

spring:
  datasource:
  	url: jdbc:oracle:thin:@1.1.1.1:1521:orcl
    username: bar
    password: 111111
    driver-class-name: oracle.jdbc.OracleDriver

此时,再执行sql:

select * from test_table;
那就相当于在bar这个schema下找表,就会报错,因为这个表在bar下不存在:
select * from bar.test_table;

此时,怎么解决呢?

要么,你还是换回foo用户连接数据库;要么,保持bar用户连接数据库,但sql中指定表的全称:

//bar用户访问foo下的表时:
select * from foo.test_table;

如果不想每个sql都这么麻烦呢?能不能全局指定一下schema呢?

当然,还有人可能会问,为啥非要用bar访问foo下的表,因为在我们这边:

老系统A,使用foo用户访问foo下的表;这次我们上新系统B,访问foo下的表时,运维或者dba要求使用新的账号,以和老系统A区分(比如权限不同,或者是方便管理,或者是通过账号就能知道是哪个系统来的连接),这种还是比较合情合理的要求,应该支持。

尝试方式1

像postgre数据库这类,都是可以url指定schema:

  datasource:
    url: jdbc:postgresql://1.1.1.1:5432/demo?currentSchema=strategy
    username: 111
    password: 111
    driver-class-name: org.postgresql.Driver

但是oracle我试了下,不行。

尝试方式2

我这边项目由于使用的是动态多数据源:

    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>dynamic-datasource-spring-boot-starter</artifactId>
        <version>4.2.0</version>
    </dependency>
    <dependency>
        <groupId>com.oracle</groupId>
        <artifactId>ojdbc6</artifactId>
        <version>11.2.0.3</version>
    </dependency>
spring:
  datasource:
    dynamic:
      enabled: true
      primary: demo
      strict: false
      grace-destroy: false
      datasource:
        demo:
          url: jdbc:postgresql://11111:5432/11111 
          username: 略
          password: 略
          driver-class-name: org.postgresql.Driver
          hikari:
            validationTimeout: 2000
            connectionTimeout: 10000
            keepaliveTime: 180000
            maxLifetime: 600000
            minimumIdle: 10
            maximumPoolSize: 10
            idleTimeout: 600000
            connectionTestQuery: ""
        foo:
          url: jdbc:oracle:thin:@1.1.1.1:1521:orcl
          username: bar
          password: 111111
          driver-class-name: oracle.jdbc.OracleDriver
          hikari:
            validationTimeout: 2000
            connectionTimeout: 10000
            keepaliveTime: 180000
            maxLifetime: 600000
            minimumIdle: 3
            maximumPoolSize: 3
            idleTimeout: 600000
            connectionTestQuery: ""

另外,连接池就直接用的spring boot默认的hikari,hikari是支持指定一个schema属性的:

        foo:
          url: jdbc:oracle:thin:@1.1.1.1:1521:orcl
          username: bar
          password: 111111
          driver-class-name: oracle.jdbc.OracleDriver
          hikari:
            schema: foo ------------------- 这里可以指定
            validationTimeout: 2000
            connectionTimeout: 10000
            keepaliveTime: 180000
            maxLifetime: 600000
            minimumIdle: 3
            maximumPoolSize: 3
            idleTimeout: 600000
            connectionTestQuery: ""

但是,最终这个schema是要传递给oracle driver那一层的,我这边这个版本的驱动,会报错。应该是高版本的driver才支持设置schema。

com.baomidou.dynamic.datasource.creator.hikaricp.HikariCpConfig

image-20260508214049057

成功的方式

我们可以指定一个初始执行的sql:

ALTER SESSION SET CURRENT_SCHEMA = foo
      hikari:
        validationTimeout: 2000
        connectionTimeout: 10000
        keepaliveTime: 180000
        maxLifetime: 600000
        minimumIdle: 3
        maximumPoolSize: 3
        idleTimeout: 600000
        connectionTestQuery: ""
        connectionInitSql: "ALTER SESSION SET CURRENT_SCHEMA = foo" ------ 这个方式

这样就可以了。各类数据库连接池框架,应该都支持类似的特性:连接建立后,执行一个初始sql。配置就大家自己查一下。

注意点

使用bar用户访问foo下的表,记得要给bar授予相关权限才行。

问题2:在nginx上配置cors的正确方式

背景

我个人其实不太习惯在nginx上配置cors,我目前手里项目是在spring boot项目里,自己写个cors的filter就实现了。但我新接手的一个项目,发现有个小问题:

nginx--》spring gateway --》 spring boot服务。

我给spring boot服务加了cors后,默认在http返回header时,就会加上cors相关的header:

Access-Control-Allow-Origin "*";

结果前端访问时,说报错了。提示有多个Access-Control-Allow-Origin header。

因为spring gateway 上也开了cors相关filter,也加了一个(按理说要判断是否后端服务已经加了,如果加了,就不应该再加了,是spring boot gateway里的配置没对,导致重复加了)。

nginx加cors

如果要临时解决上述问题,就可以在nginx上实现cors(location中加如下指令):

proxy_hide_header Access-Control-Allow-Credentials;
proxy_hide_header Access-Control-Allow-Origin;

add_header Access-Control-Allow-Credentials "true";
add_header Access-Control-Allow-Origin "*"; 

重要的是上面的proxy_hide_header,要把后端服务返回的先隐藏,否则就会有多个类似这种的Access-Control-Allow-Origin header,导致报错。

我这边配置的比较暴力,是允许了*,大家根据情况自行配置。