I just made this change in head, there is a comment in uPortal55.xml 
about connection validation and removed the actual validation queries. 
If moving to a universally valid query against a uPortal table is 
desired we can make that change. My vote would be a query against 
UP_VERSIONS since it should only have a row or two in it ensuring it 
returns very quickly.

Oh the Jira issue for my change is UP-1781

-Eric

Susan Bramhall wrote:
> If there isn't an acceptable universal validation query then I like 
> the idea of just leaving it in the comments of the current config 
> file.  There are plenty of universally valid queries for the uP 
> database if we know the schema has been created but they wouldn't work 
> for the personDB anyway since that schema is opaque.
> -Susan
>
> Andrew Petro wrote:
>> Yes, that validation query in the default context descriptor template 
>> not working in all dbs was my bad.  Brooklyn College was good enough 
>> to have me work on their portal last week and we discovered that 
>> introducing validating connections on checkout is very helpful and I 
>> was over-eager to share that default configuration with the uPortal 
>> world.
>>
>> Validating connections on checkout from the pool is in general a good 
>> thing.
>>
>> What if we were to introduce a new property in rdbm.properties 
>> supplying the validation query, to be token-replaced into the context 
>> descriptor like the other tokens are currently replaced, with 
>> examples of valid queries for each of the example RDBMS 
>> configurations in rdbm.properties?
>>
>> If a validation query isn't included in the default context 
>> descriptor, then inertia will lead to many uPortal deployments simply 
>> not using validation on connection checkout, and that seems like a 
>> missed opportunity.  Rather than rolling back the change, I'd prefer 
>> to roll forward with the further tweaks necessary to make it 
>> successful.  The problem here is not in concept -- it is in poor 
>> execution (my bad).
>>
>> Andrew
>>
>>
>>> ...I think rolling back the validation query change would be a good 
>>> thing.
>>>
>>> -Eric
>>>
>>> George Lindholm wrote:
>>>  
>>>> Cris J Holdorph wrote:
>>>>     
>>>>> safe, but not nearly as performant as the 'select 1' varities.
>>>>>           
>>>> No, but is a safe default value. And if we provide some alternate
>>>> queries like Eric suggested
>>>> each site can customize the query as appropriate.
>>>>
>>>>    George
>>>>     
>>>>> ---- Cris J H
>>>>>
>>>>> George Lindholm wrote:
>>>>>         
>>>>>> Cris J Holdorph wrote:
>>>>>>             
>>>>>>> I think the change in UP-1771 should be rolled back, until a better
>>>>>>> more cross-database solution is developed.  At least the major dbs
>>>>>>> that most uPortal deployers are using (postgres, mysql, sql server,
>>>>>>> oracle and HSQLDB for development).
>>>>>>>                   
>>>>>> The ultimate safe query would be "SELECT user_id FROM up_user WHERE
>>>>>> user_id = 1"
>>>>>>
>>>>>>   George
>>>>>>             
>>>>>>> ---- Cris J H
>>>>>>>
>>>>>>> Eric Dalquist wrote:
>>>>>>>                 
>>>>>>>> As good as a default validation query should be perhaps just a
>>>>>>>> comment in the XML file with a few examples? Having to deal with
>>>>>>>> figuring out what sort of query you need for your specific DB 
>>>>>>>> just to
>>>>>>>> develop seems like a bit of a pain.
>>>>>>>>
>>>>>>>> -Eric
>>>>>>>>
>>>>>>>> Susan Bramhall wrote:
>>>>>>>>                     
>>>>>>>>> Oh thank you!  I was wondering what broke my dev set up.  
>>>>>>>>> Since we
>>>>>>>>> know the database contains certain tables we could make it
>>>>>>>>> independent with something like "select 1 from up_versions" 
>>>>>>>>> which is
>>>>>>>>> pretty innocuous.
>>>>>>>>> Susan
>>>>>>>>>
>>>>>>>>> Parker Grimes wrote:
>>>>>>>>>                         
>>>>>>>>>> Just a quick post regarding the recent fixed issue UP-1771. The
>>>>>>>>>> validationQuery="SELECT 1" is invalid SQL in Oracle. You will 
>>>>>>>>>> end
>>>>>>>>>> up with "java.sql.SQLException: ORA-00923: FROM keyword not 
>>>>>>>>>> found
>>>>>>>>>> where expected"
>>>>>>>>>>
>>>>>>>>>> I fixed it in my uPortal55.xml file by changing that to 
>>>>>>>>>> "SELECT 1
>>>>>>>>>> FROM DUAL", but that is Oracle specific. I wonder if it would be
>>>>>>>>>> better to define that select string in the rdbm.properties 
>>>>>>>>>> file so
>>>>>>>>>> that uPortal55.xml picks it up from there and thus could be 
>>>>>>>>>> changed
>>>>>>>>>> per database vendor (since all other connection details are 
>>>>>>>>>> pulled
>>>>>>>>>> from there anyway).
>>>>>>>>>>
>>>>>>>>>> Just my thoughts,
>>>>>>>>>>
>>>>>>>>>> Parker
>>>>>>>>>> Programmer / Analyst
>>>>>>>>>> Southern Utah University
>>>>>>>>>> -- 
>>>>>>>>>> You are currently subscribed to [email protected] as:
>>>>>>>>>> [EMAIL PROTECTED]
>>>>>>>>>> To unsubscribe, change settings or access archives, see
>>>>>>>>>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev
>>>>>>>>>>                               
>>>>>>               
>>>>       
>>
>>
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to