Trying to set a portal field's value doesn't work in 3.0.9

[asppsa]

Hi there,

In my 2.1.7 code I had something like the following:

class MyModel < Rfm::Base
  config(database: 'db',
         layout: 'layout')

end

m = MyModel.new('some portal::some value' => 'testing')

In 2.1.7, this would work and I'd be able to call m.save! to update the value in the portal.
In 3.0.9, assuming that the database and layout exist, the last line above produces the following error:

/home/asp/.gem/ruby/2.1.2/gems/ginjo-rfm-3.0.9/lib/rfm/base.rb:162:in `instance_variable_set': `@some portal::some value' is not allowed as an instance variable name (NameError)
        from /home/asp/.gem/ruby/2.1.2/gems/ginjo-rfm-3.0.9/lib/rfm/base.rb:162:in `block in update_attributes'
        from /home/asp/.gem/ruby/2.1.2/gems/ginjo-rfm-3.0.9/lib/rfm/base.rb:156:in `each'
        from /home/asp/.gem/ruby/2.1.2/gems/ginjo-rfm-3.0.9/lib/rfm/base.rb:156:in `update_attributes'
        from /home/asp/.gem/ruby/2.1.2/gems/ginjo-rfm-3.0.9/lib/rfm/record.rb:148:in `initialize'
        from /home/asp/.gem/ruby/2.1.2/gems/ginjo-rfm-3.0.9/lib/rfm/record.rb:130:in `new'

As with my last bug report this is on FM14. I have been able to get around this for now with this patch, uncommenting the commented-out implementation of instance_variable_set. I've not really tried to understand what the different versions of the method are doing though.

[ginjo]

It looks like create/edit actions are broken where portals are concerned. There is a special url syntax for specifying portal fields that goes something like this

...-db=mydb&-lay=mylayout&-recid=1111&relationship::fieldname_in_portal_dot_recid.98765=some-fresh-data&-edit

for editing portal records. For creating portal records, the dot-recid becomes 0. For creating a layout record AND a related portal record, all at once, we need to fill in the fields necessary to make the relationship work, then use the related recid of 0.

The handling of this syntax was likely broken in the transition between v2 and v3. I'll refer back to the older gem and get this portal business working again.

Also, in reviewing the FM XML API, I'm seeing some other features that either have never been implemented or were lost in the v2-v3 transition, like field logic operators. I would ultimately like to support all features of the XML API... but that's a topic for another thread :-)

[ginjo]

I reviewed the 2.1.7 code, and I can't find any indication that writing to portal records has ever worked in rfm. Are you sure your above example was a portal field? Or was it just a related field on the layout but not in a portal? Writing to related fields, assuming a related record exists or can be created by FM's auto-create, should work, as long as the field is not in a portal on the layout.

I will look into various options for supporting portal-field writes, but there are some sticky hurdles to get over.

[asppsa]

Hi,

I think I am probably showing my FileMaker ignorance here. I thought that any field that had :: in it was a portal. Perhaps though this expression is reserved for cases where there is a one-many relationship?

The case I had trouble with was a one-one relationship, where a record's layout referenced a particular field in another record, and I needed to set that field to a particular value.

[ginjo]

If a Filemaker field on a layout is from any other table than the one attached to the layout, it will be a related field and have the '::' in its full field name. This is true whether or not the field is in a portal. As far as Filemaker is concerned, the only difference is that a field in a portal allows it to be enumerated for each record in the related table. In rfm, portal fields are accessed thru the 'portals' method on a record, whereas non-portal fields, even if they are related, are accessed just like any other layout field.

The nature of the relationship, one-to-many, one-to-one, won't have have any impact on how you access a related field. However, if you are trying to set data in a related field, you need a few conditions to be true.

• A related record must exist OR the auto-create feature must be enabled on that field (in filemaker).
• If using auto-create feature, the fields required to make the relationship valid must contain data,
  but they don't need to be on the layout.
• The fields you are trying to set must be accessible data fields with regard to field type and access control settings.
• You must have access to the related table in your access control settings (Filemaker security).

Stay tuned... The next release will have rudimentary write-to-portal functionality (or try it now in the master branch).

[asppsa]

Ok, so I think the title for this bug should in fact have been "Trying to set a field on a table other than the one attached to the layout doesn't work in 3.0.9". The issue was encountered trying to set WLG Current Location Sort By First::Qty and WLG Current Location Sort By First::Location on a model loaded from XML like this. e.g.

class MyModel < Rfm::Base
  config(database: 'db',
         layout: 'layout')

end

m = MyModel.new('wlg current location sort by first::qty' => 1)

[ginjo]

That code should work, if the field is on the layout you're referencing. If you could post (or gist) a raw xml from Filemaker, I can get a better idea of what's going on.