Important update for Submissions API

[10618071]

I'm not sure where the best place to post this is. I've been working on LTI tools for Canvas for about 5 years now and I consistently run into the same bottleneck. I've tried a variety of ways to solve it on my end, but haven't come up with any real solution. So, rather than try to hack my way around the problem with poor results on my side, I'd like to propose a simple change to the submissions API.

I've attached a description of the problem and my solution on this post with greater details, but the gist of the issue is getting all student submission data for a large class seems to be nearly impossible, and certainly prohibitively slow, due to how the data is returned and the size of the data set. I would sure appreciate any discussion you might have around my proposal document, maybe I am just doing it wrong? Is this something I could approach someone about on hack night at InstructureCon this year or is there a way I could have someone to look at it sooner?

[James]

10618071,

Did we ever get a clear definition of what created_at and graded_at reflect? Isn't there also and submitted_at and updated_at? I'm going from memory and not checking so I might be remembering the Canvas Data terminology from this discussion: What does the created_at field in the submission_dim represent? 

Now that I've looked at that discussion and the current API, I don't see where the current API has a created_at, just submitted_at and graded_at. Are you recommending the addition of created_at to the API call?

Instead of timestamps for each field, what if there were two start_at and end_at? I'm not enamored with the names and there's probably something more consistent with other places in the API, but it could give the submissions where any the available timestamps fell between the start_at and end_at datetimes.

You might think there's no need to have an end_at field, but if you're fetching all of the data and it's timing out, then you wouldn't be able to get the full set unless you were able to block the ending time as well. There's no guarantee (and it's probably not) that the information comes in date order. If it did, which date would it base it off of?

[10618071]

Thanks for the reply James! And thanks for pointing out that post, it was helpful.

Hmmmm... I made a mistake : ) Created_at should say submitted_at and is described in the submissions API, I fixed it on the attached file. Graded_at shows up and submitted_at is omitted when you use the submissions API to add a score directly to the gradebook, that is why I need both. I might need the other two given in the post you cited in the future, but I haven't run into them yet.

Submitted_between as you described is a good idea. It might be useful in some cases where the data is not frequently checked; for my use case, the local submissions data will be updated every time a student or teacher loads a page and should keep pace with the submissions as they come in. _between could be used in any case by giving the last_checked timestamp and now timestamp. Then now timestamp becomes the last_checked timestamp.

So, assuming this turns out to be a good and important idea, and there is no other way to do this, and the problem it solves is important, how does this become a real solution implemented in Canvas so I can use it for my LTIs?

[James]

In my thinking, both the start and end timestamps would be optional. If one of them was omitted, between would change to a before or an after. If both were omitted, it would return all values.

I'm still not advocating for a submitted_between, though, but a generic between that includes any behavior between the dates. Then you manually filter out the events that you don't need. It keeps the API simpler and more expandable without needing to come back later and revise it again when a new field is added.

I have no pull or say with what gets implemented. You can put the feature request here, but I haven't seen much in the way of development of API through the Community as it's hard to establish broad appeal for technical requirements like this. You might get on good terms with your CSM team and see if they can make the case.

I do know that large course issues are being looked at as I sat in on one of those discussions at Project Khaki a couple of weeks ago, but the main take-away of that group was whatever changes happen for large courses are things that need to happen for smaller courses as well. There might be some API changes that result as they work on that. Unfortunately, that priority was tied for last place with 2 others and there wasn't enough engineering resources devoted to allow development of all three. So I am not sure where this happens.

There may be some reports that can never run real-time and fetch all of the data that they need through the API and have to cache the data. But I agree it would be nice to know what has changed -- especially if you have a large course or one with lots of assignments. This is true not just of submissions but for many of the tables.

[10618071]

Well, that's not super encouraging! : )

Has anyone had any luck making a change like this at Hack Night at InstructureCon? Is there a forum for advocating Hack Night projects?

For me, it would be enough to know what has changed in submissions since the last request. While that is not likely a comprehensive or best solution, it removes my bottleneck and lets me make some really cool stuff! I'd be satisfied.

I thought I had what I needed in the Live Events API until I found out that it wasn't ready for prime time and it was a data dump for the entire university, not for a single course.

[MattHanes]

I can tell you that Hack Night worked very well for me. Two of the engineers worked on this one at Hack Night and eventually made it into production: https://community.canvaslms.com/ideas/2840-add-a-filter-to-moderate-quiz-screen 

And that was after one of the product managers said they wouldn't be able to add it in until the new quizzing engine! You might want to to try to submit an Idea for this so users can show support by voting: https://community.canvaslms.com/docs/DOC-2109-how-does-the-voting-process-work-for-feature-ideas 

[10618071]

Good idea Matt, thank you!

I've added the idea to the analytics2new tag

https://community.canvaslms.com/ideas/8581-make-submissions-api-work-for-large-classes 

I'd appreciate a vote up from anyone who thinks this might be useful.

[James]

To followup on my own lack of enamoration with start_at and end_at ...

Looking through the existing API calls, it looks like they primarily use start_time and end_time when restricting queries. Occasionally, it's start_date and end_date, but mostly in the calendar area and sometimes those use those as part of the data itself in other places. The data is mostly uses start_at and end_at, but not always.