Unknown record property "object" on "QubitDonor"

[suh...@gmail.com]

Hi all,

I'm getting a Symphony error "Unknown record property "object" on "QubitDonor" when trying to link a person (authority?) in the Donor/Transferring Body section of an accession record.  The issue in our tracking system is provided here:  https://intranet.library.ryerson.ca/redmine/issues/466

Has anyone else seen this error previously?  I've noticed other "unknown record property" errors discussed in this forum, but nothing relate to donors specifically (that I can find).  We are running AtoM 2.2.0-123 forked from the Artefactual github branch (no major modifications): http://github.com/ryersonlibrary/atom

From some googling, this looks like a Doctrine schema-related issue (see eg. http://symfonyexperts.com/question/showChrono/id/149), but I thought I'd post here before I look much further.  Once I'm able to get a full stack trace I'll share it.

Thanks in advance,

MJ

[Jesús García Crespo]

Hi MJ,

I think that the problem is in the way that we built autocomplete fields in AtoM. For any autocomplete field, or in this particular case the donor autocomplete field, the accession form embeds the /donor/add page using a <iframe/> element. So let's say you type in a new donor, autocomplete.js puts that value in the embedded iframe and subscribe an event in the upper form so when you submit the accession form, we ensure that the embedded forms are submitted first. When the donor is submitted (and this is still happening in the iframe), the controller redirect us to the location of the new donor, and we took that value and use it to represent the new object. You probably remember how we use routes instead of IDs to represent objects, we're doing that here.

So I think the problem is in the server not being able to respond to request originated from the embedded form before you submit the accession form. At least I used to reproduce the same error that way, trying to submit the form right after you submit the name of the new donor. Easier to reproduce on slow machines or with help of sleep().

The donor component is executed here: https://github.com/artefactual/atom/blob/qa/2.3.x/plugins/qtAccessionPlugin/modules/accession/actions/editAction.class.php#L83. I think that the exception is raised somewhere in AccessionRelatedDonorComponent or RelationEditComponent. I would set up xdebug to write the stack trace somewhere handy. It should be possible to throw that object before we try to relate it to the accession. Be aware that RelationEditComponent works for accessions-donors but it's used in many other places with other types, though that's probably not significant.

The only reason I can think we did it this way is because the XMLHTTPRequest was very new and not well supported back when this beast was engineered.

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at http://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/0d692cb3-3668-4b8b-96be-2e38b4f9b956%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jesús García Crespo,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[Jesús García Crespo]

Hi MJ,

I just wanted to send you a quick update with a link to a new ticket that has been filed recently by David. He seems to have found where the problem is: please see https://projects.artefactual.com/issues/9027.

We're planning to include a fix in AtoM 2.2.1.

Regards,

[suh...@gmail.com]

Hi Jesús!

My sincere apologies for taking so long to respond, I've been caught up with other projects and am just coming back around to AtoM now.

Thanks so much for your detailed response in explaining what's going on here; I now recall some of the XMLHTTPRequest issues that you describe, and given the amount of data on our instance, we are definitely seeing slow responses (only for certain heavily-related items, such as in this case).

I'm grateful that David and the rest of the AtoM team have filed this for including in the AtoM 2.2.1 release -- *thank you* all for your support.  Since Artefactual is going to take this on, I'll have our developers focus on some other issues affecting us, notably https://groups.google.com/d/topic/ica-atom-users/xbsSz9PUt9A/discussion

Much appreciated once again, and nice to hear from you. :)

MJ