This is basically a follow-up of https://pagure.io/pagure/issue/1404

Potentially yes, though a mere sorting would not help in my use case much - I do not even care about the order.

BTW, the dependency you set earlier on #1404 was removed by Pagure without my action. I filed #1551.

Thanks for #1551

As for the sorting, to sort we need a last_modified info, so if you want to retrieve ?modified_since or just the last_modified date/time we will need to that field :)

In that case, I fully agree!

I'm working on a patch for this (its almost done). Martin, does the same date format as 'data_created" work for you?

Question, I need to add an upgrade script to pagure/alembic/versions, but how do I generate the version ID?

Question, I need to add an upgrade script to pagure/alembic/versions, but how do I generate the version ID?

You can generate it directly via alembic: alembic revision -m "description"

I'm working on a patch for this (its almost done). Martin, does the same date format as 'data_created" work for you?

I think so, it should be the same data type in any case. Please just remember, that we need this field usable for searching in /api/0//issues call. Thanks for doing this!

I'm working on a patch for this (its almost done). Martin, does the same date format as 'data_created" work for you?

I think so, it should be the same data type in any case. Please just remember, that we need this field usable for searching in /api/0//issues call. Thanks for doing this!

Yes it is, just look for "updated_on"

{
  "args": {
    "assignee": null,
    "author": null,
    "status": null,
    "tags": []
  },
  "issues": [
    {
      "assignee": {
        "fullname": "Mark Reynolds",
        "name": "mreynolds"
      },
      "blocks": [],
      "close_status": null,
      "closed_at": null,
      "comments": [],
      "content": "hmmmm",
      "custom_fields": [],
      "date_created": "1479190005",
      "depends": [],
      "id": 2,
      "milestone": null,
      "priority": null,
      "private": false,
      "status": "Open",
      "tags": [],
      "title": "another test",
      "updated_on": "1479192372",
      "user": {
        "fullname": "Mark Reynolds",
        "name": "mreynolds"
      }
    },

This looks good, please note I am talking about being able to query by this argument. I.e. so that I can make API call like

/api/0/<repo>/issues?since=2016-11-15

and get only issues with updated_on that is the same or newer.

Question, I need to add an upgrade script to pagure/alembic/versions, but how do I generate the version ID?

You can generate it directly via alembic: alembic revision -m "description"

Having some minor issues...

cd /pagure/alembic
alembic revision -m "add updated_on column to issues"
FAILED: No config file 'alembic.ini' found, or file has no '[alembic]' section

So I went to pagure/files where the alembic.ini file is:

$ alembic revision -m "add updated_on column to issues"
FAILED: Path doesn't exist: '/usr/share/pagure/alembic'. Please use the 'init' command to create a new scripts folder.

$ alembic init -t ../alembic/script.py.mako ../alembic/versions/
FAILED: Directory ../alembic/versions/ already exists

What is the proper process to do this?

Thanks,
Mark

@mreynolds run the alembic command at the top level of the project something like:

cp files/alembic.ini .
vim alembic.ini # edit the sqlalchemy url
alembic revision...

get only issues with updated_on that is the same or newer.

I always wonder, what is the desired behavior when the date provided is invalid, return a 400 error or what arrow is likely to do, return the date 1970-01-01 and use that date. In other words, do we want to check the format of the date provided and raise and error if that date doesn't follow it, or do we want to be more flexible?

Note that we should return the date considered in the JSON anyway, for the client to check that the date returned matches the one it sent, so eventually that would allow us to use the more flexible road while still giving a way to check/debug the input submitted.

This looks good, please note I am talking about being able to query by this argument. I.e. so that I can make API call like
/api/0//issues?since=2016-11-15

and get only issues with updated_on that is the same or newer.

Yeah that doesn't seem to be working at all - but I did not touch the "query" code

http://localhost.localdomain:5000/api/0/DS2/issues?since=150000000

No matter what I use after the "?": "since", "updated_on", and whatever value I use, all the issues are returned:

127.0.0.1 - - [15/Nov/2016 10:02:14] "GET /api/0/DS2/issues?updated_on=1479192372 HTTP/1.1" 200
127.0.0.1 - - [15/Nov/2016 10:02:31] "GET /api/0/DS2/issues?since=1479192372 HTTP/1.1" 200 -
127.0.0.1 - - [15/Nov/2016 10:04:00] "GET /api/0/DS2/issues?since=150000000000 HTTP/1.1" 200 
127.0.0.1 - - [15/Nov/2016 10:04:15] "GET /api/0/DS2/issues?updated_on=150000000000 HTTP/1.1" 200 -

@mreynolds we can do that one step at a time, merge first the updated_on addition, add the filtering in the UI/API in a second change.

@mreynolds we can do that one step at a time, merge first the updated_on addition, add the filtering in the UI/API in a second change.

I already started looking into this code (and making some progress), but yes I agree I'll do this as a second patch. I'll work on wrapping up the first patch of just adding "updated_on".

Thanks,
Mark

SIDE NOTE - When I click "Update Issue" is clears the form. It happened over and over. I had to refresh this page to make it stop happening. It seems to happen after the page was auto refreshed. Known issue?

Not sure, could it be #1333?

Odd, not sure what triggered it, but I think I've been running into it a lot. I think I thought I was accidentally hitting the "Clear" button

@mreynolds run the alembic command at the top level of the project something like:
cp files/alembic.ini .
vim alembic.ini # edit the sqlalchemy url
alembic revision...

Getting closer:

alembic revision -m "add updated_on column to issues"
FAILED: Multiple heads are present; please specify the head revision on which the new revision should be based, or perform a merge.

How do I find the correct head revision?

Thanks again,
Mark

you can check alembic history to see all the revision, then you can edit your file to be on the top of the one currently in git

you can check alembic history to see all the revision, then you can edit your file to be on the top of the one currently in git

Thanks, the history showed the problem. Turns out it was my own hacked script in the versions directory that was throwing things off. I took it out and the revision command worked fine :-) Patch coming shortly...

"Phase 1" patch attached, please review at your earliest convenience.

Thanks,
Mark

I have completed the query aspect of "updated_on". The following patch is the total patch, so the previous patch can be ignored.

I added a new search argument "since" that accepts either a timestamp or a datetime string, and returns all the issues from that time and forward:

/api/0/MY_PROJECT/issues?since=1479261135
or
/api/0/MY_PROJECT/issues?since=2016-11-15

I also added validation for each type.

Please review when you get a chance.

Thanks,
Mark

@mreynolds I will apply your patch to a branch and turn it into a pull-request, it will make it easier to comment on the code this way :)

You can then just keeping sending new patches or the same one corrected and I'll update the PR as we go.

Here is the corresponding PR https://pagure.io/pagure/pull-request/1561

Latest and greatest patch:

This is looking good, I might had a commit or two on the top of it if you do not mind and then I think we should be able to merge it :)

Final patch? This one includes API testing as well

hm, looks like the patch no longer applies cleanly, do you think you could try rebasing it? I'm going to start viewing as it is for now

@mreynolds are you by any chance on IRC?

rebased patch

I am on irc "mreynolds" on #389, and internal to RedHat #dirsec

Thanks, I'll ping you when I get back if I have more comments :)

Fixed in #1561