>
> the patch looks reasonable, but it will need extra logic to cope with
> nullsFirst/nullsLast
>
Not sure I follow. Do you mean there is more to be fixed, or that the
change breaks things in some way in some cases?
Could you expand on what you mean exactly by 'logic to cope with
https://www.traviscistatus.com/ says that all open-source builds are
stopped.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I have h2 database in server mode for my tests (oracle mode)
I can't add/subtract an interval to my date, in my spring-batch writer,
when my request works in SQLDeveloper
How to do this whith h2
1) UPDATE MY_TABLE SET my_date = (sysdate - INTERVAL '1' SECOND);
2) UPDATE MY_TABLE SET my_date =
Just for information: Travis CI cancels some builds, but GitHub displays
them as “The Travis CI build is in progress” anyway, propably this status
is not supported by GitHub.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from
sorry, we don't support those oracle functions
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group,
H2 has a lot of compatibility modes and there are three possible ways for
NULL handling.
If compatibility mode sets uniqueIndexSingleNull database throws error on
the first match. No more rows can contain the same data. Only one iteration
in any case.
If compatibility mode sets
I mean that nulls can sort either first or last, so there might be (I'm not
sure) more checking required to see if it legitimate to exit the loop early
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop
Simple test case:
CREATE TABLE TEST(ID BIGINT PRIMARY KEY, NAME VARCHAR);
CREATE UNIQUE INDEX NAME_IDX ON TEST(NAME);
INSERT INTO TEST(ID) SELECT X FROM SYSTEM_RANGE(1, 1);
Each new row causes iterations over all previous in *checkUnique()*.
I don't know how NULLS FIRST and NULLS LAST can
BaseIndex.compareRows() treats nulls as equal due to a == b check in
compareValues(). Notice that nulls stored as Value.NULL, not as null, so
null check in compareRows() is another story.
It means that we repeatedly check only rows with exactly the same key
values (nulls treated as equals to
