RE: What Am I missing?

Liquibase lets you automate your glitches 😊

From: William Robertson <william_at_williamrobertson.net> Sent: Tuesday, September 8, 2020 9:49 AM To: oracle-l <oracle-l_at_freelists.org> Cc: Jeff Smith <jeff.d.smith_at_oracle.com> Subject: Re: What Am I missing?

Absolutely, scripts should tested using whatever tool is used for deployment, ideally automatically using Team City or similar. I have a "Run with SQL*Plus" tool defined in my menu bar. I think this is possible with all the main IDEs. I'd just say that an IDE is not generally a practical tool for automating deployments, and a CLI is not much use for interactive development, so two separate tools are pretty much inevitable.

I've heard a lot about Liquibase, though I haven't used it, but now I'm wondering if there is some way to accidentally glitch that as well.

William

On 8 Sep 2020, at 14:32, Jeff Smith <HYPERLINK "mailto:jeff.d.smith_at_oracle.com"jeff.d.smith_at_oracle.com> wrote:

Using one tool to build said scripts and using another tool to deploy said scripts is a recipe for…bad things.

Your devs should be testing everything with SQL*Plus if that’s how their code ends up in the real world.

From: William Robertson <HYPERLINK "mailto:william_at_williamrobertson.net"william_at_williamrobertson.net>  Sent: Tuesday, September 8, 2020 9:05 AM To: oracle-l <HYPERLINK "mailto:oracle-l_at_freelists.org"oracle-l_at_freelists.org> Subject: Re: What Am I missing?

That will work in this particular case, assuming the script contains exactly one object definition and nothing else, and we don't mind losing blank lines.

But I can create the function in PL/SQL Developer anyway, so the problem only arises when the source code file is run using SQL*Plus as part of a deployment. If we have some deployment framework that calls SQL*Plus and we change it to get & run everything, it will then fail on other scripts that contain multiple statements. Or if we change this particular script to get & run itself that could work, but it would be less effort just to move the slash character, and we would still have our blank lines.

Anyway the point I was making was that it's unfair to blame the PL/SQL parser, which I felt was somewhat implied by "It's a PL/SQL parser bug." It's more of a limitation of a CLI that needs a "stop input and execute" character which happens to be the same as a language operator. You’d hit the same issue with a SQL statement.

William

On 8 Sep 2020, at 10:40, Sayan Malakshinov <HYPERLINK "mailto:xt.and.r_at_gmail.com"xt.and.r_at_gmail.com> wrote:

Hi William,

As I said previously that's just a problem of command processing with pretty easy workaround: just save your ddl as a script and use `get file.sql` command to put its content into the buffer and run using /

On Tue, Sep 8, 2020 at 12:34 PM William Robertson <HYPERLINK "mailto:william_at_williamrobertson.net"william_at_williamrobertson.net> wrote:

I wouldn't call it a PL/SQL parser bug. The client tool doesn't know it's PL/SQL and splits the code at the / character, producing an incomplete function followed by some unparsable lines which never reach the PL/SQL compiler. I'm amazed that I've never seen this before but I can reproduce it in SQL*Plus 19.0.0.0.0.

I'm not sure what else SQL*Plus could do, to be honest, as / means run and there is no way to change it.

William

-- 

Best regards,
Sayan Malakshinov

Oracle performance tuning engineer

Oracle ACE Associate
HYPERLINK "https://urldefense.com/v3/__http:/orasql.org/__;!!GqivPVa7Brio!LYx56aAY5ou-8eqHz36a2fyLZpAGooxrx5dCKv8A7WYnocQMEasvJ5_uz4f7qUUmg6s$"http://orasql.org

--

http://www.freelists.org/webpage/oracle-l Received on Tue Sep 08 2020 - 16:32:21 CEST