Support lazy loading of Projects

[tjrivera]

No description provided.

[sburns]

Definitely a great idea. The issue I ran into at some point is that some (most?) code paths (e.g. exporting & importing DataFrames, any file-related method) depend on the project being configured because they assume attributes like def_field, field_names, etc. So to truly maintain backwards compatibility, you'll need to self.configure() before the guts of some of these methods. Which really means that we've just moved the metadata API call from initialization to when it's actually needed. But that's the definition of lazy, right?

Perhaps a little more documentation is in order about what this means? One of the advantages of issuing metadata API call so early is that the application quickly knows if the credentials are correct and that the API is responsive.

[tjrivera]

By default initialization will still occur just as before here. If a project is initialized "lazily" a user could still get all that configuration at any time by running Project.configure()

My use case here is the use of PyCap to drive real-time interaction with REDCap in a web application. My application essentially proxies calls to REDCap for an arbitrary project. As a result the metadata calls on initialization could get pretty costly from an app performance point of view. In my case, I know most of the metadata (def_field, field_names, forms, etc) up front.

I'll try and add a bit more documentation here for clarification. Thanks for the feedback

[sburns]

So you're going to do something like this?

lazy_project = Project('https://redcap.foo.edu/api', 'bar', lazy=True)  # super fast construction
lazy_project.def_field = 'something I know'
lazy_project.field_names = ('field_names', 'that', 'i', 'will', 'use', 'later')
# now really use the lazy_project

Because if you don't set some of these attributes on your own, some methods are going to silently break.

[tjrivera]

In my case I want to be able to quickly initialize a project and use the export_records function as a quick and easy abstraction of calls to the REDCap API. I recognize some things will fail silently, but I don't rely on those things for the majority of my calls and exporting records still behaves as I would expect.

I do recognize the confusion it might cause if one were to initialize lazily and find much of their attributes empty. I'll add some code to configure the project as necessary on certain function calls.

I guess the question then becomes -- should this be the default behavior? With Project attributes only being pulled as needed?

[sburns]

I'd like this PR to stay as is and if you don't mind, please explore what it means to use a lazy project (ie when do you need to add attributes, when not, etc) ? It would obviously be a 2.0-type of change that should be in a separate PR.

[tjrivera]

Hi Scott, I added a little more clarification as to the purpose behind lazily loading projects. Essentially it exists to quickly Initialize a Project object -- anticipating that calls to it (i.e. export_records) will occur later in the objects lifecycle. Feel free to merge if you're happy with the PR.

[sburns]

thanks @tjrivera !