Model.new fields missing if done after a failed Model.find

[emptyflask]

If I run Mover.new first, I get the expected behavior, and @model.field_names is correctly populated.

Running Mover.find(...) with an empty result set and then Mover.new creates an empty hash, and @model.field_names is empty.

Seems like Rfm is relying on the first connection to Filemaker to populate the layout, even if that connection doesn't return any layout data.

Tested with Ruby 2.2.0, Filemaker 13, rfm 3.0.9

[ginjo]

@emptyflask, @traels, sounds like the meta data is just not loading when it should... which of course causes all kinds of problems down the line. I'll have to review the code to find out why it's not loading, but I see two possible solutions.

• Raise an exception when the meta doesn't load when it should.
• Keep trying to load the meta, when it's needed, no matter what the situation.

I'd like to find something in the middle of those two - make meta loading more robust/reliable, while a true failure to load would raise an exception. Comments welcome if anyone sees problems with that approach.

@asppsa, just including you here in case you think the portal problem could also be related to missing meta data.

[asppsa]

Hi there. #24 is definitely a metadata-related issue. The exception raised is the result of trying to access non-existent data in resultset.portal_meta -- see line 26 of datum.rb.

[emptyflask]

Linking 73b378a to this issue. I'll try to test this later today...

[ginjo]

Ok, so to sum up what I did in the commit mentioned above...

The meta missing problem is more of a design flaw than a specific coding bug. I originally had the layout object looking at the first-returned resultset meta, when possible, for things like field names and portal meta. The problem with this is that a null found set returned from FM doesn't have any resultset meta - it is instead considered an error (401).

So I adjusted the layout object to verify that any stored resultset meta is valid, and if not, get a new empty resultset using FM's -view action (returns a fully valid - but empty - resultset).

Meanwhile, the 401 error is silent by default but can be made noisy with config :raise_on_401 => true

I'll follow up later today and also address the PR's. Thanks all for the feedback.

[traels]

Thank you! Looking forward to remove monkey patches from my code :)