Re: XSL SQL Library Extension Modification

Tue, 02 Dec 2003 13:45:16 -0800

Eric,

Depends on how you use Stylesheets in JEdit. If you notice, XConnection actually creates a
pool using the driver + URL + user + password as the identifying string. In the Stylesheet,
before connect, set the parameter "default-pool-enabled" to be true. It will then start the code
to pool connections. Now you need to keep an instance of the Stylesheet around so that the
ConnectionPoolManager is not GC'ed. Subsequent calls to the Stylesheet or other Stylesheets
that use the same connection metrics should pull information from the existing pool.
See XConnection#init( String driver, String dbURL, Properties prop )

Regards
John G

Eric J Everman wrote:

John-

Thanks again, but I'm *way* over time on this project and need to move on
for now.

I do have a few quick questions:  Is it possible to close just the current
query and keep the connection within a stylesheet?  Failing that, is there
a way to use a connection pool within a stylesheet (ie not use an external
one)?  I'm working within JEdit to process the XSL, so I'd rather not
create external connections to use a pool.

Thanks again for your help.  If I had started looking at this extension
earlier, I probably would have had the time to make the change we talked
about.  As it was, I had complete over half the project before realizing
that this was as option.  Next time...

If you'd rather that the question above be posted to the user's list, I can
post it there as well.

Thanks,

Eric Everman



John Gentilin <[EMAIL PROTECTED] To: Eric J Everman <[EMAIL PROTECTED]> ing.com> cc: Subject: Re: XSL SQL Library Extension Modification 11/25/2003 06:13 PM 




I have abstracted most of the Xalan API out in DTMDocument. At least
most of the leg work
is done for you. There is one outstanding issue that multi chunk
document are not supported
yet.  The DTM ID is a bit field broken down into two parts, the Document
ID and the NodeID
Xalan builds a specialized DOM structure that has and external DTM
mapping, the SQL extensions
just use the DTm mapping live and fake out the API to make it thing it
is talking to a DOM API
but it is really fetching the data directly from a RecordSet although
this in not quite true for
non streaming mode. The DTM is fairly simple, there are multiple integer
arrays i.e. _parent
_child. So if you are at a particular element and you want to jump to
you parent, you take your
current NodeID an use it as an index into the _parrent array to fetch
the NodeID of your parent.
It just makes XPath evaluation easier For your extension, I don't think
you will need to dive in
too deep into the Xalan API, it is more of the "creative" coding that is
only implemented in the
SQL extensions. For the most part coding will be easy,  multiple result
sets may be tricky since you
always need to know what column set you are currently working on but if
I am not mistaken, its is
always the current result set so as you cross over results sets, you
need to push the current column
name table and create a new one. If you have questions, feel free to
either email me or give me a call
510-881-4821.

Regards

-John G


Eric J Everman wrote:



John-

Thanks for the encouragement. I looked at this for a good part of the
afternoon and realized that I really don't understand the Xalan API - in
particular the DTM. I'll have to throw in the towel for now since I'm


gone


for the rest of the week.

Thanks Again,

--ee










John Gentilin





<[EMAIL PROTECTED] To: Eric J Everman


<[EMAIL PROTECTED]>


ing.com> cc:





Subject: Re: XSL SQL


Library Extension Modification


11/25/2003 02:45





PM













Eric,

This might be really easy, but there are a few twists to watch out for.
First be sure you understand the memory usage in the SQL extension.
I was trying to be as efficient as possible, so the attributes are only
allocated
in the Metadata section of the code, then the DTM ID's are cloned for
each
row. The tricky part here is when you are evaluating a parent or child
from
the attribute, you need to be aware that its not the natural parent /


child


but
probably a row. Also the SQL extension produces two schema's depending
if you want support for multiple result-sets. and Streaming Mode allocates
memory differently that non Streaming mode.

Your proposal looks like its on the right track, we just need to make sure
the other mechanism don't break. From a quick glance, it looks like it
would
work just fine. You could probably build a Vector/Array in
extractSQLMetaData
to capture the column data to build a Name table so a translation of


Column


# converts to the Name Table ID for the Column and use that number instead
of  m_Col_TypeID in the call to addElementWithData.

With multiple result sets, you need to be aware that the Metadata / column
names
could change between result sets and if Streaming mode is disabled you can
just
trash the previous Name Table.

Also I think Xalan is still stuck on the JDK 1.1.8 standard, an internal
IBM thing.

So after all that, I would say go for it. If you have questions feel free
to ask and when
you finish, I will review the changes and commit them for you.

Regards
John G


Eric J Everman wrote:
    John-

    I am working on a modification to the XSL SQL Library Extension.
    What I
    would like to add is the option to use the real column names instead
    of the
    generic <col> element names.  I'm trying to transform the data after
    it
    comes out of the database, and I finding it to be very complex (and
    buggy)
    to attempt to do it w/o named data elements.

    So, this is what I am proposing:
    -Add a 'useColNames' attribute to the query and pquery functions
    (Yes/No -
    default No)
    -Add a 'colNameCase' attribute to the query and pquery functions
    (Upper/Lower/Unchanged - default Upper)

    The case option is important b/c the tag matching is case sensitive,
    so it
    makes it much easier to be consistent.

What are your thoughts - any suggestions? I've been looking thru


the


code
and it looks like I the columns are constructed and cached in
SQLDocument.createExpandedNameTable(). My thinking is that I need


to


    have
    this method create an entry in the ExpandedNameTable for each column
    name,
    then retrieve the correct ENT entry for each column in
    addRowToDTMFromResultSet().

Does it sound like I am on the correct track?

Thanks,

    Eric Everman
    USGS





John Gentilin

                          <[EMAIL PROTECTED]        To:       Eric J
    Everman <[EMAIL PROTECTED]>

ing.com> cc:

                                                   Subject:  Re: XSL SQL
    Library Extension

11/24/2003 01:20

PM







Hi Eric,

    Thanks for the pointer. I know about this , it is covered in bug
    http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12337
    Actually now that you sent this email I will rattle a few cages, the
    bug
    is not in the SQL extension but part of the iterator
    used to recurse the row-set.  Do me a favor and post your message on
    the
    xalan-dev list to create a stir about it.

    Regards
    John G

Eric J Everman wrote:


Hi John-

          Thanks for your work on the SQL extension - I'm just starting
          to use if

for

          my current project and I really appreciate that it is
          available.

          I don't know if you are the person to inform, but I thought I
          would let
          someone know that the sample provided on the apache site at:
          http://xml.apache.org/xalan-j/extensionslib.html#ex-sql

does not work as is. The tag:
<xsl:apply-templates select="$table/sql/row-set/row"/>
results in only a single data row from my db. I changed it


to:


          <xsl:apply-templates select="$table/sql/row-set"/>
          and it now returns all rows.

I assume this is an outcome of a single row being returned at


a


          time, but
          it would be nice if the sample pointed out why the one method
          works and

why

the other doesn't.

Thanks again!

          Eric Everman
          USGS






    --
    --------------------------------------
    John Gentilin
    Eye Catching Solutions Inc.
    18314 Carlwyn Drive
    Castro Valley CA 94546

        Contact Info
    [EMAIL PROTECTED]
    Ca Office 1-510-881-4821
    NJ Office 1-732-422-4917









--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546

  Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917








--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546

   Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917











--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546

   Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917

Reply via email to