Added XML support for procedures and functions

[jgebal]

No description provided.

[jgebal]

This partly resolves #28
Still, missing table support not validated, not implemented)
There are some samples with RubyOCI8 here

[jgebal]

@javornikolov any comments/concerns?

[javornikolov]

Are we sure about the behavior in case of data type 'UNDEFINED' and type name != 'XMLTYPE'? (Before it used to end it else/else clause. Now we trap it here leaving bind values unset).

[javornikolov]

@jgebal, any opinion about that question? My concern is that we're maybe changing the semantics of non-xmltype 'UNDEFINED' (even though I'm not sure what exactly that might be).

[jgebal]

Hi Yavor.
I'll look into it this week.
Thanks for spotting that potential behavior change.
Jacek
On 25 Oct 2015 18:33, "Yavor Nikolov" notifications@github.com wrote:

In lib/plsql/procedure_call.rb
#91 (comment):

@@ -236,6 +236,14 @@ def add_argument(argument, value, argument_metadata=nil)
@bind_values[argument] = value.nil? ? nil : (value ? 1 : 0)
@bind_metadata[argument] = argument_metadata.merge(:data_type => "NUMBER", :data_precision => 1)
"l_#{argument}"

•  when 'UNDEFINED'
  

•    if argument_metadata[:type_name] == 'XMLTYPE'
  

•      @declare_sql << "l_#{argument} XMLTYPE;\n"
  

•      @assignment_sql << "l_#{argument} := XMLTYPE(:#{argument});\n" if not value.nil?
  

•      @bind_values[argument] = value if not value.nil?
  

•      @bind_metadata[argument] = argument_metadata.merge(:data_type => "CLOB")
  

•      "l_#{argument}"
  

•    end
  

@jgebal https://github.com/jgebal, any opinion about that question? My
concern is that we're maybe changing the semantics of non-xmltype
'UNDEFINED' (even though I'm not sure what exactly that might be).

—
Reply to this email directly or view it on GitHub
https://github.com/rsim/ruby-plsql/pull/91/files#r42948271.

[jgebal]

I assume that all the existing functionality is covered by unit tests and all existing unit tests are passing.
I did not verify what other types fall under UNDEFINED, but for sure none of them is currently supported by framework.

[javornikolov]

There are some other other UNDEFINED types (I'm checking that on http://sqlfiddle.com/):

select
  data_type, type_name, type_subname, pls_type, count(*) as cnt
from
  all_arguments a
where
  a.data_type = 'UNDEFINED'
group by
  data_type, type_name, type_subname, pls_type

It's an edge case indeed, yet I'm wondering about the behavior (how gracefully does it fail) when facing some of these unsupported types.

[jgebal]

Regardless of the change introduced the unsupported datatypes (like ANYDATA) will not work.
But you're right that there is a change in the evaluation for UNDEFINED datatypes.
This can be changed so the rest of UNDEFINED fall into the behaviour prior to the change.
I'm not sure what would be the difference since one way or the other the types like ANYDATA are not supported.

[javornikolov]

OK. We may consider examining the unsupported features behaviour a separate topic.

[javornikolov]

Merged. Thank you @jgebal for the contribution!

[jgebal]

Thanks Yavor.
I'm sort on time recently though I'd like to contribute more.
On 1 Nov 2015 21:52, "Yavor Nikolov" notifications@github.com wrote:

Merged. Thank you @jgebal https://github.com/jgebal for the
contribution!

—
Reply to this email directly or view it on GitHub
#91 (comment).