/changes and LIMIT parameter

Google Groups archive
1

Hello,

might be some issues when using LIMIT parameter (version 1.11.2)

example

Done is true and Last is 5821

/changes/?limit=4
result: changes 5454-5457

/changes/?limit=4&since=5700
result: changes 5454-5457

/changes/?since=5700&limit=4
result: changes 5701-5800

/changes/?since=5700&limit=120
result: changes 5701-5800

/changes/?limit=120&since=5700
result: changes 5454-5573

/changes/?since=5818&limit=40
result: changes 5819-5821

/changes/?limit=40&since=5818

result: changes 5454-5493

2

Hi,

Which DB plugin are you using? Just tested with SQLite and no issue.

We once noticed that the MongoDB plugin seemed to have issues with the /changes route.

Best regards,

Alain

3

Thanks Alain,

We’re using the PostgreSQL plugin, version 4.0

4

Hi,

So here’s how I’ve tested it:

  • started this setup
  • uploaded around 600 instances → my last change is 604

http://localhost/changes/?limit=10000 → returns all 604 changes, done=true → OK

http://localhost/changes/?limit=4 → returns first 4 changes, done=false → OK

http://localhost/changes/?limit=4&since=500 → returns 501-504, done=false → OK

http://localhost/changes/?since=500&limit=4 → returns 501-504, done=false → OK
http://localhost/changes/?since=1000&limit=4 → returns no changes, done=true → OK

Please, provide equivalent steps to reproduce the problem you are observing.

Best regards,

Alain.

5

Thanks Alain.

Similar setup, using postgres 12.1

/changes/?limit=10000
result: changes 5454-5821, done=true

/changes/?limit=4
result: changes 5454-5457

would anything “reset” the first change to a number higher than 1?
in our case, it appears that our first change is now 5454.

does order matter? should we always use “since” before “limit”?

but we can’t explain the following results:

/changes/?limit=4&since=5700
result: changes 5454-5457 (instead of 5701-5704)

/changes/?since=5700&limit=4
result: changes 5701-5800 (instead of 5701-5704)

/changes/?since=5818&limit=40
result: changes 5819-5821

/changes/?limit=40&since=5818

result: changes 5454-5493 (instead of 5819-5821)

6

Hi,

Changes are deleted when their resource is deleted → this explains why your changes do not start at 0 (you have deleted the first studies that have been uploaded).

The argument order has no impact (at least it should not and we have never observed it).

I’m sorry but I’ll need you to provide me with a complete setup in order to reproduce the issue since I’m not able to reproduce it here. You should very likely start from this setup.

Best regards,

Alain.

7

thanks. here’s the docker-compose.yml setup

orthanc:

image: osimis/orthanc
container_name: orthanc
depends_on:

  • postgres
    restart: always
    ports:
  • ‘4242:4242’
    networks:
  • frontend
  • backend
    volumes:

configuration file

  • ${ORTHANC_CONFIG:-./config/orthanc.json}:/etc/orthanc/orthanc.json:ro
    environment:
  • POSTGRESQL_PLUGIN_ENABLED=true
    command: /etc/orthanc

postgres:
image: postgres:12.1
container_name: postgres
restart: always
networks:

  • backend
    volumes:
  • ${POSTGRES_DATA_MNT}:${PGDATA}
    environment:
  • POSTGRES_USER=${POSTGRES_USER}
  • POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
  • PGDATA=${PGDATA}
  • POSTGRES_DB=orthanc
8

Hi,

Thanks, but that does not allow me (or you) to reproduce the error. I would need sample data and a set e.g curl command to upload/delete data in order to reproduce exactly the issue: a complete test scenario.

The fact is this route is very simple, tested and used in production at many places without anyone ever noticing any issue so if there is an issue with this route, it is not “that” simple to reproduce.

Best regards,

Alain.