tn3rb
commented
1 year ago
- Is there a more straightforward method to read that data?
LOLZ, no sorry, uh... welcome to REST APIs?
Unfortunately with any REST API there is a 1:1 relationship between an endpoint and a specific resource. Any kind of relational data will require multiple queries to retreive that data. There really is no way around that other than to use something other than REST, such as GraphQL which can return a full set of relational data in a single query. But unfortunately, our GraphQL implementation is not completed fully and therefore can most likely not be used to retrieve the data you require.
- If not, is there a recommended approach
That kinda depends on what you are doing with the data once you've received it. If you are intending to generate objects out of the data and need to maintain relationships between the objects, then I would probably start with top level objects like Transactions which are on the "1" side of 1:many relationships. But even this is totally arbitrary depending on what you are going to do with the data and how you write code. So ultimately it's kinda up to you to do whatever you want. Sorry I don't have a better answer.
- I notice that putting in a call for attendees gives a lot of old data and doesn't include up-to-date data.
In Event Espresso, an attendee is our data model for a person that has attended an event. Their record of having attended an event is saved in the Registraion model. An attendee can have multiple registrations associated with them (such as a returning customer). New attendee records are only created whenever a new uniqiue person has been identified. This is done by comparing the person's first name, last name, and email address. If an existing attendee record is found with those three items matching, then no new record is created and the existing one is used. Therefore, attendee records with lower IDs represent attendees that have been in the system longer, but do not necessarily mean they do not have any current related registrations. What you are observing is likely fairly typical, but is also a result of how people are attending your events (ie: repeat customers will use an existing attendee record if the name and email fields match, but you are seeing more unique one time attendees).
Now, all of that said, if you are finding that too many attendee records associated with old registrations are being returned and you are having to perform too many "paging" queries to retreive the rest of the data, then you have (at least) a couple of options.
You could try:
-
sorting your attendee queries by descending ID so that newer records associated with more recent registrations are returned first, therefore requiring less paging to get to the additional attendees you want
-
querying for the relevant registrations you are interested in, then extracting the related attendee IDs from those records (the
ATT_IDfield) and then use those to query for the attendee records you want. This of course would be extremely taxing if you do it record by record, but there may be a way to incorporate thoseATT_IDvalues in a query that can return multiple records at a time.
Is this a bug or am I misunderstanding what this call does? Is there a different call to get a list of attendees?
It sounds to me like your definition of an attendee is more like our definition of a registration. It's confusing because the terminology can easily have a lot of overlap. A good way to understand our definitions is to imagine a use case where you have a multiday conference with multiple workshops occurring during the conference. Let's assume you are setting things up in the following manener:
- the main conference is represented in Event Espresso by an Event
- the main conference has an associated datetime that spans all of the days of the conference
- this primary datetime has its own ticket for gaining entrance to the conference
- each workshop is represented by a separate datetime within the event that details the exact day and time that the workshop occurs
- each workshop has its own ticket (so 1:1 reltionship between tickets and datetimes)
John Doe decides to go to the conference and sign up for three workshops. This will result in the following records being created (not inculding records for the above entities):
- 1 attendee record based on John Doe's first name, last name, and email address
- 1 transaction record for John Doe's ticket purchases (assuming everything was all purchased at the same time)
- 1 registration record for the main conference, with foreign keys to the transaction, ticket, and attendee records
- 3 registration records, one for each of the workshops, with foreign keys to the transaction and attendee records matching the registration above for the conference, but with different foreign keys for the tickets, since each workshop (as well as the conference) have their own tickets.
So even though you have a total of 4 registration records created for that single transaction, there is only one attendee record created for John Doe, because he was the same attendee for the conference and each workshop.
I hope that helps you out and good luck with whatever awesome thing you are building.
Cowthulu
Hello -
I am trying to use the EE REST API to essentially read all of the data that is present in the report that you get when you run the Registration CSV export. It seems like I can assemble the data, but it requires a lot of sub-queries. A few questions: