You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by John Gentilin <ge...@eyecatching.com> on 2003/12/02 21:40:46 UTC

Re: XSL SQL Library Extension Modification

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                                                                                                         
>                      <gentijo@eyecatch        To:       Eric J Everman <ee...@usgs.gov>                                                 
>                      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
>>    
>>
>
>  
>
>>                     <gentijo@eyecatch        To:       Eric J Everman
>>    
>>
><ee...@usgs.gov>
>  
>
>>                     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
>>
>>                           <gentijo@eyecatch        To:       Eric J
>>     Everman <ee...@usgs.gov>
>>
>>                           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
>>     gentijo@eyecatching.com
>>     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
>>gentijo@eyecatching.com
>>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
>gentijo@eyecatching.com
>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
gentijo@eyecatching.com
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917