location_cck field values not synced with location_instance table

hey Ryan,

see if the patch/solution for http://drupal.org/node/343943 helps you... (should work for D5 version, too)

cheers,

daniel

I think this could be marked as by design since you don't necessarily want the locations data duplicated. It's showing up in the CCK field where it's supposed to and the CCK tables are handling the instance join between node and location.

For the 6.x code it's not a problem because you can add a relation from the cck table to the location table ala #347030: location_cck needs a views relation.

Yes, it is by design. It's just that location_cck isn't completely integrated yet, like drewish said.

okay, Brandon, the site admin creating an location_cck field should have the possibility to _choose_ whether the field's location_instance stores the nid/vid, too, so they resp. nodes are handeled transparently via the proximity-views-filter in a simple and compatible way (compatible to other nodes of other location-enabled-non-location_cck-types, that is).
If a specific field should not be linking the entered location to the nid/vid in location_instance, then you could just leave the checkbox "link field' location to nid/vid" unchecked.
How about that?
If it'll be committed, i can implement this and provide a patch.

i think an having an option to sync with the location table would be a good idea. it would follow the pattern set by other modules like content_taxonomy. i'd suggest leaving it disabled by default. it seems like a recipe for problems if there are multiple fields on the same node type and they're all trying to write data to the location_instance table... how would one field know that it wasn't updating/replacing another field's locations so you might end up with duplicates, missing locations, etc.

@drewish: Such collisions can (and will?!) happen right now, regardeless of additionally storing nid/vid, since the field's location instance data gets already stored and connected in location_instance table, but probably with too little/too ambigous data there:
@Brandon: The field instance's _delta_ should get stored in the location_instance.genid, too (which stores at the moment only fieldname and node.vid), to prevent possible data collision (again: regardless of an option to also save nid/vid info there).

danielnolde, well just because it might(?) be a problem now doesn't mean that we should try to make it a problem in the future. as for deltas i'd suggest that rather than enhancing the location_instance table, we should focus on making location_cck the primary way of associating locations to nodes.

hm, there may be some misunderstanding regarding how location_cck works, drewish:

> i'd suggest that rather than enhancing the location_instance table, we should focus on making location_cck the primary way of associating locations to nodes.

location_cck fields already just reference a location that logically gets stored in {location}/{location_instances} tables, where by basic design location.module stores all it's location data. I.E. the location_cck field tables is just cck field wrapping mechanism referencing a {location}.lid.

> just because it might(?) be a problem now doesn't mean that we should try to make it a problem in the future.

the additional storage of nid/vid in a {location_instance} already referenced by a location_cck field does not add *any* problems in terms of data integrity.

The only in some cases unwanted behaviour introduced by that, would be that then a node having a location_cck field gets itself "location aware", and perhaps some specific location_cck field for sme specific site should deliberately be not found by e.g. a proximity filter and instead just add a raw location info and not making the whole node location-aware - only in some cases for some sites, that is.

But this has to be defined by the respective needs of the respective application, hence the suggestion of letting the field creator chose whether to additionally story the node's nid/vid into {location_instance} or not.
I think more than ever that this is the best way to go and offers the most flexibility with little effort (probably just a few lines of additional code for that field-config-option in location_cck.module).

The storage is by design.

Additionally, I wish gmap_location would go away and be replaced by a couple of views. :P

Maybe if I implemented some default views.... ;)

Can someone who has been following this please post a summary of the current thinking on this?

Tagging.

Based on bdragon's comments above. I'm tempted to mark this "by design".

marked #363698: Make cck location nodes appear in views as a duplicate of this issue

Subscribe.

subscribed.

Duplicate and still an ongoing issue #391160: CCK/Views: location_instance fix