You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2012/05/23 18:51:04 UTC
Dependency of DBCPConnectionFactory on ExampleType entity
I just realized that line 150 in DBCPConnectionFactory:
factory.setValidationQuery("select example_type_id from example_type limit 1");
is a dependency on ExampleType entity declared in the "example" component.
This is probably not a big deal but now that we have moved the "example" component to specialpurpose it is more important to have framework code not dependent on it.
What is your preference to fix this? Some options I can think of:
1) modify the sql to use SequenceValueItem or another entity declared in the same component (or, less ideally, another framework component like "commons")
2) add the sql to a properties file to make it configurable (and change it as above); a small advantage with this approach is that a user could set it to null to turn off validation:
http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/PoolableConnectionFactory.html#setValidationQuery(java.lang.String)
3) figure out if we can find a trick and run an SQL command that doesn't require a table
4) other ideas?
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>
> On May 23, 2012, at 7:34 PM, Adam Heath wrote:
>
>> On 05/23/2012 12:05 PM, Jacopo Cappellato wrote:
>>>
>>>> DBCPConnectionFactory is in framework/entity; having it require a
>>>> framework/entity/entitymodel seems the safest approach.
>>>
>>> I agree; what if we use:
>>>
>>> select count(testing_type_id) from testing_type where testing_type_id = 'ABC'
>>
>> Actually, no, TestingType seems like it is an entity that would never
>> be installed in a production environment; I certainly would never want
>> to install testing-only things.
>>
>> SequenceValueItem, EntityKeyStore always need to be in the *current*
>> datasource. Tenant* might be in another datasource, so you can't test
>> for those.
>>
>> count() also seems wrong, as it might be a heavy-weight operation. Is
>> this particular thing going to run often? That's an important thing
>> to consider if you switch the entity.
>>
>> What about using DatabaseMetadata? But that might have performance
>> issues. What does this check actually hope to accomplish? I haven't
>> read the code(sorry), and don't have time now to fully study it all.
>
> Yeah, it is executed quite often (as far as I understand it) and we should use an efficient SQL that returns at least one record:
> the sql is used by DBCP to check if the connection is good and (I think) it is executed everytime the connection is
> borrowed/returned (but I don't remember exactly, it could be less often).
> I would also prefer to use one of SequenceValueItem or EntityKeyStore but I am worried that SequenceValueItem is a very used
> entity... EntityKeyStore may be a better choice.
> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we
> are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very
> low number of rows... but I too would prefer to avoid it.
An entity in entity component seems a wise choice if ever someone wants to extract the entity engine (good luck).
But it seems to me that EntityKeyStore can be empty. I see it on trunk demo and in a the current project I'm working on (a large
application).
On the other hand I agree that SequenceValueItem is not a good choice (we have already SELECT FOR UPDATE there with
SequenceBank.fillBank() method)
We could also rely on something external to entity component, but for the reason explained before it's less appealing.
I think that the select limited to 1 is a good idea, but maybe something else can be used on even a possible empty entity?
Ha no:
http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/PoolableConnectionFactory.html#setValidationQuery%28java.lang.String%29
must returns 1 line...
Why not create a specific entity in entity component loaded with 1 line only used for that?
Jacques
> Jacopo
>
>>
>>> that should always return one row with the 0 count; the entity is empty ootb (it is only used for automated tests) but the
>>> constraint on the pk should add an additional protection for efficiency.
>>
>> Well, that proves it, it really shouldn't create the entity except
>> during a test run. That's something I've been wanting to fix for
>> awhile now.
>
>
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Thanks Jacques.
However "values 1" works in Derby (but not from the Webtools, because of a limitation in the data prep script).
Jacopo
On May 24, 2012, at 11:33 AM, Jacques Le Roux wrote:
> SELECT 1 FROM SYSIBM.SYSDUMMY1 works for Derby. If all others work with SELECT 1 we could set a property in entityengine.xml (by DB)With SELECT 1 for all but Derby and SELECT 1 FROM SYSIBM.SYSDUMMY1 for Derby. We could also use the same trick for other DBs if SELECT 1 does not work for them (eg Oracle has the dual table I read)I found the same idea at http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_0_9_3/build.properties.default (look for SELECT 1)But unfortunately VALUES 1 does not work with DerbyJacquesFrom: "Jacopo Cappellato" jacopo.cappellato@hotwaxmedia.com> > On May 24, 2012, at 10:37 AM, Jacques Le Roux wrote:> >> "select 1" works on Postgres> > this is interesting, thanks for testing it.> Unfortunately it doesn't seem to work on Derby and I didn't test on other dbs... but if we could find a similar solution that works everywhere it would be great.> > Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacques Le Roux <ja...@les7arts.com>.
SELECT 1 FROM SYSIBM.SYSDUMMY1 works for Derby. If all others work with SELECT 1 we could set a property in entityengine.xml (by
DB)With SELECT 1 for all but Derby and SELECT 1 FROM SYSIBM.SYSDUMMY1 for Derby. We could also use the same trick for other DBs if
SELECT 1 does not work for them (eg Oracle has the dual table I read)I found the same idea at
http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_0_9_3/build.properties.default (look for SELECT 1)But unfortunately VALUES 1
does not work with DerbyJacquesFrom: "Jacopo Cappellato" jacopo.cappellato@hotwaxmedia.com> > On May 24, 2012, at 10:37 AM, Jacques
Le Roux wrote:> >> "select 1" works on Postgres> > this is interesting, thanks for testing it.> Unfortunately it doesn't seem to
work on Derby and I didn't test on other dbs... but if we could find a similar solution that works everywhere it would be great.> >
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 24, 2012, at 10:37 AM, Jacques Le Roux wrote:
> "select 1" works on Postgres
this is interesting, thanks for testing it.
Unfortunately it doesn't seem to work on Derby and I didn't test on other dbs... but if we could find a similar solution that works everywhere it would be great.
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On May 24, 2012, at 9:04 AM, Jacques Le Roux wrote:
>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> On May 23, 2012, at 9:25 PM, Adam Heath wrote:
>>>
>>>> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>>>>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that
>>>>> we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with
>>>>> a very low number of rows... but I too would prefer to avoid it.
>>>>
>>>> select 1;
>>>
>>> Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
>>> I will test the system with it and then commit.
>>>
>>> Jacopo
>>
>> Which entity will you use Jacopo?
>
> When I first saw Adam's comment I thought he was suggesting to simply execute
>
> "select 1"
>
> in order to run a "query" with no table to return a "record" with one field containing 1.
> But I maybe misunderstood the suggestion and at least on Derby this doesn't seem to work; but I still need to fully test.
> In my opinion adding a new entity for this would be an overkill; one solution could be the following:
>
> select count(key_name) from entity_key_store where 1 = 2
>
> that always returns one record and should be efficient on mostly all dbs.
Sounds good. My idea of a new entity was also to make clear what it was about.
"select 1" works on Postgres
Jacques
> Jacopo
>
>
>>
>> Jacques
>
>
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Raj,
Good idea, I had the same, please re-read the thread ;o)
Cheers
Jacques
From: "Rajbir Saini" <ra...@yahoo.com>
> How about defining a test sql statement in entityegine.xml which could be specific to DBMS. For example 'select * from dual" in
> oracle and MySQL, "Select 1" in PostgreSQL. Idea is to use the DBMS specific SQL and make it configurable in the entityengine.xml
> so that it can be configured while configuring the datasource.
>
> Thanks,
>
> Raj
>
> On Thursday 24 May 2012 08:48 PM, Jacopo Cappellato wrote:
>> On May 24, 2012, at 5:06 PM, Adam Heath wrote:
>>
>>> select 1 from entity_key_store where key_name = '' limit 1;
>> ouch, I am getting an error on Derby for the "limit 1" syntax... since it is currently used in the validation query based on
>> "Example" I am now wondering if it is actually used at all.
>> I will skip the limit 1 because as you mentioned key_name is a pk and this should still guarantee that 0 records are returned
>>
>> Thanks
>>
>> Jacopo
>
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Rajbir Saini <ra...@yahoo.com>.
How about defining a test sql statement in entityegine.xml which could
be specific to DBMS. For example 'select * from dual" in oracle and
MySQL, "Select 1" in PostgreSQL. Idea is to use the DBMS specific SQL
and make it configurable in the entityengine.xml so that it can be
configured while configuring the datasource.
Thanks,
Raj
On Thursday 24 May 2012 08:48 PM, Jacopo Cappellato wrote:
> On May 24, 2012, at 5:06 PM, Adam Heath wrote:
>
>> select 1 from entity_key_store where key_name = '' limit 1;
> ouch, I am getting an error on Derby for the "limit 1" syntax... since it is currently used in the validation query based on "Example" I am now wondering if it is actually used at all.
> I will skip the limit 1 because as you mentioned key_name is a pk and this should still guarantee that 0 records are returned
>
> Thanks
>
> Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 24, 2012, at 5:06 PM, Adam Heath wrote:
> select 1 from entity_key_store where key_name = '' limit 1;
ouch, I am getting an error on Derby for the "limit 1" syntax... since it is currently used in the validation query based on "Example" I am now wondering if it is actually used at all.
I will skip the limit 1 because as you mentioned key_name is a pk and this should still guarantee that 0 records are returned
Thanks
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On May 24, 2012, at 5:06 PM, Adam Heath wrote:
>
>> On 05/24/2012 03:22 AM, Jacopo Cappellato wrote:
>>>
>>> On May 24, 2012, at 9:04 AM, Jacques Le Roux wrote:
>>>
>>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>>> On May 23, 2012, at 9:25 PM, Adam Heath wrote:
>>>>>
>>>>>> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>>>>>>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that
>>>>>>> we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity
>>>>>>> with a very low number of rows... but I too would prefer to avoid it.
>>>>>>
>>>>>> select 1;
>>>>>
>>>>> Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
>>>>> I will test the system with it and then commit.
>>>>>
>>>>> Jacopo
>>>>
>>>> Which entity will you use Jacopo?
>>>
>>> When I first saw Adam's comment I thought he was suggesting to simply execute
>>>
>>> "select 1"
>>>
>>> in order to run a "query" with no table to return a "record" with one field containing 1.
>>> But I maybe misunderstood the suggestion and at least on Derby this doesn't seem to work; but I still need to fully test.
>>> In my opinion adding a new entity for this would be an overkill; one solution could be the following:
>>>
>>> select count(key_name) from entity_key_store where 1 = 2
>>
>> Ah, grr, I'm so used to postgres, sorry for the trick not working.
>>
>> In oracle, postgres, and mysql, the following works. It returns 0
>> rows, but tests the connection, and sql parsing in the server. Would
>> this be good enough?
>>
>> select 1 from entity_key_store where key_name = '' limit 1;
>>
>> Using '1 = 2' still causes a SEQ_SCAN on the table(explain in postgres
>> says this). key_name has an index on it, so that part is faster.
>> Since key_name is the primary key, you might not need the limit, but
>> it couldn't hurt(except for a slightly slower parsing of the sql).
>
> Yeah, I like it, thanks man!
>
> Jacques: it is probably not a bad idea to add an attribute to make it configurable from the datasource xml setup but at the moment
> I would not spend too much time on this; if you want I can create a Jira ticket with low priority as a reminder for the future.
> But I would actually avoid it also because the new JDBC API has a isValid (or similar) method that should replace this trick at
> some point in the future.
OK then forget it ;o)
Jacques
> Thanks again,
>
> Jacopo
>
>
>
>
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 24, 2012, at 5:06 PM, Adam Heath wrote:
> On 05/24/2012 03:22 AM, Jacopo Cappellato wrote:
>>
>> On May 24, 2012, at 9:04 AM, Jacques Le Roux wrote:
>>
>>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>>> On May 23, 2012, at 9:25 PM, Adam Heath wrote:
>>>>
>>>>> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>>>>>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very low number of rows... but I too would prefer to avoid it.
>>>>>
>>>>> select 1;
>>>>
>>>> Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
>>>> I will test the system with it and then commit.
>>>>
>>>> Jacopo
>>>
>>> Which entity will you use Jacopo?
>>
>> When I first saw Adam's comment I thought he was suggesting to simply execute
>>
>> "select 1"
>>
>> in order to run a "query" with no table to return a "record" with one field containing 1.
>> But I maybe misunderstood the suggestion and at least on Derby this doesn't seem to work; but I still need to fully test.
>> In my opinion adding a new entity for this would be an overkill; one solution could be the following:
>>
>> select count(key_name) from entity_key_store where 1 = 2
>
> Ah, grr, I'm so used to postgres, sorry for the trick not working.
>
> In oracle, postgres, and mysql, the following works. It returns 0
> rows, but tests the connection, and sql parsing in the server. Would
> this be good enough?
>
> select 1 from entity_key_store where key_name = '' limit 1;
>
> Using '1 = 2' still causes a SEQ_SCAN on the table(explain in postgres
> says this). key_name has an index on it, so that part is faster.
> Since key_name is the primary key, you might not need the limit, but
> it couldn't hurt(except for a slightly slower parsing of the sql).
Yeah, I like it, thanks man!
Jacques: it is probably not a bad idea to add an attribute to make it configurable from the datasource xml setup but at the moment I would not spend too much time on this; if you want I can create a Jira ticket with low priority as a reminder for the future.
But I would actually avoid it also because the new JDBC API has a isValid (or similar) method that should replace this trick at some point in the future.
Thanks again,
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Adam Heath <do...@brainfood.com>.
On 05/24/2012 03:22 AM, Jacopo Cappellato wrote:
>
> On May 24, 2012, at 9:04 AM, Jacques Le Roux wrote:
>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> On May 23, 2012, at 9:25 PM, Adam Heath wrote:
>>>
>>>> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>>>>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very low number of rows... but I too would prefer to avoid it.
>>>>
>>>> select 1;
>>>
>>> Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
>>> I will test the system with it and then commit.
>>>
>>> Jacopo
>>
>> Which entity will you use Jacopo?
>
> When I first saw Adam's comment I thought he was suggesting to simply execute
>
> "select 1"
>
> in order to run a "query" with no table to return a "record" with one field containing 1.
> But I maybe misunderstood the suggestion and at least on Derby this doesn't seem to work; but I still need to fully test.
> In my opinion adding a new entity for this would be an overkill; one solution could be the following:
>
> select count(key_name) from entity_key_store where 1 = 2
Ah, grr, I'm so used to postgres, sorry for the trick not working.
In oracle, postgres, and mysql, the following works. It returns 0
rows, but tests the connection, and sql parsing in the server. Would
this be good enough?
select 1 from entity_key_store where key_name = '' limit 1;
Using '1 = 2' still causes a SEQ_SCAN on the table(explain in postgres
says this). key_name has an index on it, so that part is faster.
Since key_name is the primary key, you might not need the limit, but
it couldn't hurt(except for a slightly slower parsing of the sql).
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 24, 2012, at 9:04 AM, Jacques Le Roux wrote:
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> On May 23, 2012, at 9:25 PM, Adam Heath wrote:
>>
>>> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>>>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very low number of rows... but I too would prefer to avoid it.
>>>
>>> select 1;
>>
>> Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
>> I will test the system with it and then commit.
>>
>> Jacopo
>
> Which entity will you use Jacopo?
When I first saw Adam's comment I thought he was suggesting to simply execute
"select 1"
in order to run a "query" with no table to return a "record" with one field containing 1.
But I maybe misunderstood the suggestion and at least on Derby this doesn't seem to work; but I still need to fully test.
In my opinion adding a new entity for this would be an overkill; one solution could be the following:
select count(key_name) from entity_key_store where 1 = 2
that always returns one record and should be efficient on mostly all dbs.
Jacopo
>
> Jacques
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On May 23, 2012, at 9:25 PM, Adam Heath wrote:
>
>> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we
>>> are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a
>>> very low number of rows... but I too would prefer to avoid it.
>>
>> select 1;
>
> Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
> I will test the system with it and then commit.
>
> Jacopo
Which entity will you use Jacopo?
Jacques
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 23, 2012, at 9:25 PM, Adam Heath wrote:
> On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
>> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very low number of rows... but I too would prefer to avoid it.
>
> select 1;
Thank you Adam, this is the "trick" I was looking for when I mentioned option #3 in my first email.
I will test the system with it and then commit.
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Adam Heath <do...@brainfood.com>.
On 05/23/2012 01:13 PM, Jacopo Cappellato wrote:
> Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very low number of rows... but I too would prefer to avoid it.
select 1;
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 23, 2012, at 7:34 PM, Adam Heath wrote:
> On 05/23/2012 12:05 PM, Jacopo Cappellato wrote:
>>
>>> DBCPConnectionFactory is in framework/entity; having it require a
>>> framework/entity/entitymodel seems the safest approach.
>>
>> I agree; what if we use:
>>
>> select count(testing_type_id) from testing_type where testing_type_id = 'ABC'
>
> Actually, no, TestingType seems like it is an entity that would never
> be installed in a production environment; I certainly would never want
> to install testing-only things.
>
> SequenceValueItem, EntityKeyStore always need to be in the *current*
> datasource. Tenant* might be in another datasource, so you can't test
> for those.
>
> count() also seems wrong, as it might be a heavy-weight operation. Is
> this particular thing going to run often? That's an important thing
> to consider if you switch the entity.
>
> What about using DatabaseMetadata? But that might have performance
> issues. What does this check actually hope to accomplish? I haven't
> read the code(sorry), and don't have time now to fully study it all.
Yeah, it is executed quite often (as far as I understand it) and we should use an efficient SQL that returns at least one record: the sql is used by DBCP to check if the connection is good and (I think) it is executed everytime the connection is borrowed/returned (but I don't remember exactly, it could be less often).
I would also prefer to use one of SequenceValueItem or EntityKeyStore but I am worried that SequenceValueItem is a very used entity... EntityKeyStore may be a better choice.
Using count() was simply a trick to be sure to get a record back even if the entity is empty... but if we use an entity that we are sure is populated we don't have to use it, of course. Of course if we use count(*) we have to use it in an entity with a very low number of rows... but I too would prefer to avoid it.
Jacopo
>
>> that should always return one row with the 0 count; the entity is empty ootb (it is only used for automated tests) but the constraint on the pk should add an additional protection for efficiency.
>
> Well, that proves it, it really shouldn't create the entity except
> during a test run. That's something I've been wanting to fix for
> awhile now.
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Adam Heath <do...@brainfood.com>.
On 05/23/2012 12:05 PM, Jacopo Cappellato wrote:
>
>> DBCPConnectionFactory is in framework/entity; having it require a
>> framework/entity/entitymodel seems the safest approach.
>
> I agree; what if we use:
>
> select count(testing_type_id) from testing_type where testing_type_id = 'ABC'
Actually, no, TestingType seems like it is an entity that would never
be installed in a production environment; I certainly would never want
to install testing-only things.
SequenceValueItem, EntityKeyStore always need to be in the *current*
datasource. Tenant* might be in another datasource, so you can't test
for those.
count() also seems wrong, as it might be a heavy-weight operation. Is
this particular thing going to run often? That's an important thing
to consider if you switch the entity.
What about using DatabaseMetadata? But that might have performance
issues. What does this check actually hope to accomplish? I haven't
read the code(sorry), and don't have time now to fully study it all.
> that should always return one row with the 0 count; the entity is empty ootb (it is only used for automated tests) but the constraint on the pk should add an additional protection for efficiency.
Well, that proves it, it really shouldn't create the entity except
during a test run. That's something I've been wanting to fix for
awhile now.
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On May 23, 2012, at 6:53 PM, Adam Heath wrote:
>>
>> 1) modify the sql to use SequenceValueItem or another entity declared in the same component (or, less ideally, another framework component like "commons")
>
> DBCPConnectionFactory is in framework/entity; having it require a
> framework/entity/entitymodel seems the safest approach.
I agree; what if we use:
select count(testing_type_id) from testing_type where testing_type_id = 'ABC'
?
that should always return one row with the 0 count; the entity is empty ootb (it is only used for automated tests) but the constraint on the pk should add an additional protection for efficiency.
Jacopo
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Adam Heath <do...@brainfood.com>.
On 05/23/2012 11:51 AM, Jacopo Cappellato wrote:
> I just realized that line 150 in DBCPConnectionFactory:
>
> factory.setValidationQuery("select example_type_id from example_type limit 1");
>
> is a dependency on ExampleType entity declared in the "example" component.
>
> This is probably not a big deal but now that we have moved the "example" component to specialpurpose it is more important to have framework code not dependent on it.
>
> What is your preference to fix this? Some options I can think of:
>
> 1) modify the sql to use SequenceValueItem or another entity declared in the same component (or, less ideally, another framework component like "commons")
DBCPConnectionFactory is in framework/entity; having it require a
framework/entity/entitymodel seems the safest approach.
Re: Dependency of DBCPConnectionFactory on ExampleType entity
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Hey,
I just discovered that entity-config.xsd already supports the ability to set a validation query:
pool-jdbc-test-stmt
I am going to change the code to use this.
Jacopo
On May 23, 2012, at 6:51 PM, Jacopo Cappellato wrote:
> I just realized that line 150 in DBCPConnectionFactory:
>
> factory.setValidationQuery("select example_type_id from example_type limit 1");
>
> is a dependency on ExampleType entity declared in the "example" component.
>
> This is probably not a big deal but now that we have moved the "example" component to specialpurpose it is more important to have framework code not dependent on it.
>
> What is your preference to fix this? Some options I can think of:
>
> 1) modify the sql to use SequenceValueItem or another entity declared in the same component (or, less ideally, another framework component like "commons")
> 2) add the sql to a properties file to make it configurable (and change it as above); a small advantage with this approach is that a user could set it to null to turn off validation:
> http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/PoolableConnectionFactory.html#setValidationQuery(java.lang.String)
> 3) figure out if we can find a trick and run an SQL command that doesn't require a table
> 4) other ideas?
>
> Jacopo
>
>
>
>