On 24.10.2016 15:39, Niclas Hedhman wrote:
Thanks for the help, Stan... Really appreciated that you still watch what
is going on here.
You're welcome, Niclas! :)
I do watch this, just not always enough time to post meaningful reply,
or the topic is a bit out of scope (e.g. entities) for me after all
these years. :)
On Mon, Oct 24, 2016 at 8:37 PM, Niclas Hedhman <nic...@hedhman.org> wrote:
Ii have figured it out... I missed the "reconnect to the jdbc_test_db as a
superuser". My ltree addition happened outside the database
"jdbc_test_db"... On my way now.
On Mon, Oct 24, 2016 at 8:30 PM, Niclas Hedhman <nic...@hedhman.org>
wrote:
If I go back to psql, I get this informative message
postgres=# CREATE EXTENSION ltree;
ERROR: extension "ltree" already exists
On Mon, Oct 24, 2016 at 8:23 PM, Niclas Hedhman <nic...@hedhman.org>
wrote:
Caused by: org.postgresql.util.PSQLException: ERROR: type "ltree"
does not exist
Position: 55
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2453)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2153)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:286)
Is there an easy way to test ltree presence with the psql command line?
On Mon, Oct 24, 2016 at 8:20 PM, Niclas Hedhman <nic...@hedhman.org>
wrote:
Ah, I see...
stmt.execute( this._vendor.toString( d
.createTableDefinitionBuilder()
.setTableScope( TableScope.LOCAL_TEMPORARY )
.setTableName( t.tableName( "ltree_test" ) )
.setCommitAction( PgSQLTableCommitAction.DROP )
.setTableContentsSource(
d.createTableElementListBuilder()
.addTableElement(
d.createColumnDefinition( "test_column", dt.userDefined( "ltree" )
) )
.createExpression() ).createExpression() ) );
is the code executed and ANY SQLException will cause my InternalError,
and SQLException is not shown. Adding the root cause and running again.
On Mon, Oct 24, 2016 at 8:16 PM, Stanislav Muhametsin <
stanislav.muhamet...@zest.mail.kapsi.fi> wrote:
On 24.10.2016 15:05, Niclas Hedhman wrote:
I managed to install postgres locally and set up according to your
instructions. I even needed to figure out that postgresql-contrib
package
was needed for the "ltree" to work (accepted inside psql command
line).
However, I now get an error in the testcases;
<failure message="java.lang.InternalError: It seems that your
database
doesn't have ltree as type. It is needed to store collections. Please
refer to hopefully supplied instructions on how to add ltree type
(hint: run <pg_install_dir>/share/contrib/ltree.sql script or
command 'CREATE EXTENSION ltree;')."
type="java.lang.InternalError">java.lang.InternalError: It seems that
your database doesn't have ltree as type. It is needed to store
collections. Please refer to hopefully supplied instructions on how to
add ltree type (hint: run
<pg_install_dir>/share/contrib/ltree.sql script or command
'CREATE EXTENSION ltree;').
root@devdesk:~# su postgres
postgres@devdesk:/root$ psql
could not change directory to "/root": Permission denied
psql (9.4.9)
Type "help" for help.
postgres=# CREATE EXTENSION ltree;
CREATE EXTENSION
postgres=# \q
Any ideas??
Indexing-SQL uses some SQL command to test whether ltree extension is
installed.
I totally forgot what is the command, and I can not access Zest
codebase right now.
Can you see the root cause via debugger, the first exception that is
thrown, most likely causes this.
It *might* be that the exception is something else, but the
Indexing-SQL *thinks* it is because of failing ltree-test.
On Mon, Oct 24, 2016 at 7:46 PM, Paul Merlin <p...@nosphere.org>
wrote:
So, I ran integration tests and everything is stable except
indexing-sql.
A lot of the query tests fail.
Something about mapping Identity to String is incomplete.
I've attached the tests result report to ZEST-180 and pointed to the
test setup instruction there.
Paul Merlin a écrit :
Niclas,
The Identity change is quite massive, and affects many tests,
especially in
the Entity Stores and Indexing/Query subsystems.
The changes builds on my local Linux system, but I notice that
Redis and
Riak (others?) test suites are disabled, and I have not look into
making
them run locally. So there may still be issues, and I am not at all
surprised if the CI will fail.
And I need to go to sleep now, so it may take a couple of days for
this
to
stabilize.
Cheers
All integration tests that depend on external services are skipped
if
they can't reach the corresponding external service.
For most of them, simply running the service with the default
configuration is enough (Memcached, Redis, Riak, MongoDB).
The SQL EntityStore is always tested against embedded databases
(Derby,
H2, SQLite). If a MySQL or PostgreSQL service is available it will
be
tested against them too. The SQL Index/Query is only tested against
PostgreSQL if available. PostgreSQL needs some special setup
(user/pass
and some extension for indexing, documented in the corresponding
extension).
The CI do not run any of these external services.
Three years ago I did start creating a Docker image with almost all
of
these services (https://github.com/eskatos/zest-docker-testbed).
It's
completely outdated now. I do have a very limited connection these
days
so I won't be able to update it soon. But I have all the services
locally so I'll try and run the integration tests to see if
something
broke.
Ideally we should build such a Docker image during the build and
run the
test suite into it on CI.
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
