Then I would say... go ahead :-D
Cheers
Andrea
On Sat, Apr 25, 2020 at 11:37 AM Mark Prins wrote:
> Fails on master with an old driver, fixed in the PR by adding a getter for
> the expected.
>
> Op za 25 apr. 2020 10:31 schreef Andrea Aime >:
>
>> But first the question: was it failing before?
Fails on master with an old driver, fixed in the PR by adding a getter for
the expected.
Op za 25 apr. 2020 10:31 schreef Andrea Aime :
> But first the question: was it failing before?
> Tests are often added to the base JDBC*Test classes, and tested on a bunch
> of them only... like,
> NOT Oracl
But first the question: was it failing before?
Tests are often added to the base JDBC*Test classes, and tested on a bunch
of them only... like,
NOT Oracle :-D
Cheers
Andrea
On Sat, Apr 25, 2020 at 3:10 AM Jody Garnett wrote:
> My first thought is the previous driver also had to wrestle with Ora
My first thought is the previous driver also had to wrestle with Oracle's
representation of Numbers and was able to sort things out.
* Can we find any logic that handled this previously?
* Can we step through the old code with a debugger and see how it made the
decision to convert from BigDecimal
Op di 21 apr. 2020 om 17:51 schreef Mark Prins :
> While working on this PR https://github.com/geotools/geotools/pull/2890
> to have Online testing of the Oracle JDBC module I'm running into some
> failing tests.
>
> OracleFeatureSourceOnlineTest>OnlineTestCase.run:112->JDBCFeatureSourceOnlineTes
While working on this PR https://github.com/geotools/geotools/pull/2890
to have Online testing of the Oracle JDBC module I'm running into some
failing tests.
Some may have to do with how the user is defined in Oracle, but one of
the failures definitely isn't and the failure line is slightly cr
Travis is giving a green light on this PR:
https://travis-ci.org/github/geotools/geotools/jobs/677166629 after I
disabled the failing testBBOX3DOutsideLine() test, there some issues with
the filter geometry loosing the 3-rd dimension in one or two locations in
the code, see https://osgeo-org.atlass
On Thu, Apr 16, 2020 at 12:07 PM Mark Prins wrote:
> I've just opened https://github.com/geotools/geotools/pull/2880 to bring
> SQL server online testing as a job on Travis-CI as currently there seems no
> environment that runs those. Right?
>
Correct, there is indeed no environment running SQL
I've just opened https://github.com/geotools/geotools/pull/2880 to bring
SQL server online testing as a job on Travis-CI as currently there seems no
environment that runs those. Right?
Mark
--
Disclaimer;
This message is just a reflection of what I thought at the time of sending.
The message may
I don't anticipating it being too heavy a load. The test data for the
jdbc datastores is quite small. A handlful of tables with a few records.
That said there would be a lot of traffic going back and forth between
the hudson server and the db instance doing setup more or less for each
test case
Good points. Probably best to keep the hudson instance local to the
network where the db servers are.
On 5/8/10 1:21 AM, [email protected] wrote:
> Hmmm
>
> If have a VM running db2,oracle-xe,postgis and mysql. Additionally there
> is a VM
> running Oracle 10.2 for Georaster testing.
>
>
Also any concern of how heavy the the load will be on the internet? I
assume the tests involve lots of data transfer so might use up lots of
bandwidth. On the plus side, such tests mimics real world situations
more closely.
-1 for Sending plain text passwords. but then again adding protection
for
Hmmm
If have a VM running db2,oracle-xe,postgis and mysql. Additionally
there is a VM
running Oracle 10.2 for Georaster testing.
A Windows VM is on the to do list.
I intended to integrate Online tests after
gis.linux4all.at/hudson32
gis.linux4all.at/hudson64
are clean, but looking at these h
Hi all,
I am currently working on getting GEOT-1981 updated and hopefully will
apply to trunk shortly after I get a review.
http://jira.codehaus.org/browse/GEOT-1981
After which I would like to start setting up online jobs in hudson for
all the jdbc datastores so that we can continuously run t
That is only on trunk right now; it would not be hard to back port
(right Cory?)
Making use of it is a one of the QA goals for trunk,
Jody
> Hey all,
>
> Is the OnlineTestCase and related framework stuff in-place on 2.3.x, or
> is it a trunk-only thing?
>
> Working from here:
> http://docs.codeh
Hey all,
Is the OnlineTestCase and related framework stuff in-place on 2.3.x, or
is it a trunk-only thing?
Working from here:
http://docs.codehaus.org/display/GEOT/5.+7+Testing
Just checking.
thanks!
--saul
-
Using Tomcat
Rob Atkinson wrote:
> as in either option is fine?
Yup.
> OK - I think I understand - the _filename_ is nogeos.properties. Not
> sure what the fixture ID is used for
Well the fixture id is used to locate the properties file. For instance
the fixture id "postgis.nogeos" tells the test to look in t
>>
>> 1) if the online build is going to run tests, does it automatically load
>> from the SVN http://svn.geotools.org/geotools/trunk/gt/build/fixtures/
>> path into the testing environments home directory?
>>
> Not as written, its up to the developer to copy them into their home
> director
Rob Atkinson wrote:
> apropos the instructions on online tests at
> http://docs.codehaus.org/display/GEOT/5.+7+Testing
>
>
> Trying to make sense of this...
>
> under http://svn.geotools.org/geotools/trunk/gt/build/fixtures/ are
> some sample fixtures.
>
> the online test talks about the use
apropos the instructions on online tests at
http://docs.codehaus.org/display/GEOT/5.+7+Testing
Trying to make sense of this...
under http://svn.geotools.org/geotools/trunk/gt/build/fixtures/ are
some sample fixtures.
the online test talks about the user's home directory containing
fixtures
20 matches
Mail list logo
