I realize that changing this is likely beyond the 3.x scope, but perhaps it's time to discuss 4.x (for D7)

The way location_instance is a multi-type table, storing both uids and nids, means it's (nearly) impossible to share this table between 2 sites...

A typical multi-site shared db does something along the lines of this:

DB A - Only Nodes in Site A , Shared Users
DB B - Only Nodes in Site B, Shared Users
DB User - shared with both A & B, contains user tables, sessions, and other tables that are user related, so both sites can access non-node based info.

If Location were broken into location, location_user and location_node, sharing the location table (with lids), and the location_user table (with uids<->lid relationships) would work great, and no sharing of the location_node table (with nid/vid/genid<->lid relationships)
But the mix means that potentially (realistically-> _usually_), nids in the location_instance table will point to the wrong NID (ie Nid in Site B, but really refers to Nid in Site A) meaning the data will be all wrong, and conflict, etc.

Splitting location_instance into location_user and location_node would mean a few things would have to change (views integration, some other functions would have to become smarter), but I believe this could be done behind the scenes with little in the way of API changes. Doing query with both users and nodes at the same time becomes _slightly_ harder, since it's no longer a single table, but still doable - and honestly, mixing nodes and users is a bad thing: they are different sorts of objects, and need different method of display/theming/etc/etc...

Right now, I'm looking at a project that this is a showstopping bug (both sites require user locations, and potentially node locations (one has, the other might in the future), and unless someone has some positive suggestions, I'm looking at having to hack location 6.x-3.x to split it now... I'd rather contribute this change back to the community, but this seems like too big a change for 6.x-3.1 at this point, really it's a 4.x level of difference... D7?

Comments

hefox’s picture

hefox commented

Stumbled on this, not maintainer; I believe CCK location field connects via lid to the table, and also I believe location module is in general leaning toward using CCK field more than location_node.

himerus’s picture

himerus commented

I'm with Seth on this one. (regarding the same project we are on)

I think the issue here is simply with nodes (node location &/OR CCK location values) & users are separate entities, and should be treated as such in the database schema in order to provide scalability and ease of use within multisite environments with shared tables.

In our current situations, all USER related data is shared across sites, but the node data is not. The storage mechanism for location is storing all locations in a single table which now can't be shared unless some custom module hacking/glue is written to add logic of when it's a user location, go to the shared table, and when it's a node or cck location reference, go to the local table.

This I think is just a situation where the initial concept of the schema didn't take into account a complicated multisite environment. We are still researching alternatives on how this can be best accomplished in our current situation, and it very well may take patching the location module, and hoping for the best, and that something can be accepted into the current branch of the module.

I think though this MUST be considered a priority in the D7 branch for location as Drupal becomes more flexible, so should the "upper echelon" of modules, and Location is definitely among those.

I am a fan of using CCK location over node locations, but I think for the sake of sanity, it should have 3 tables for locative information, one for node locations, one for cck locations, and one for user locations. This will allow any table(s) that need to be shared to happen in a logical way, which again in our case is ONLY the user data being shared.

bdragon’s picture

bdragon commented

The only reason location_instance exists really is so I can garbage collect unreferenced locations. I'm not so sure nowadays that it was the best idea, or even if it really matters.

Really, the only thing that needs to be in one table are the coordinates (which I'd really like to punt over to geo sometime in the future btw) and the only reason for THAT is speed. (it's hard enough to do coordinate searches in raw sql, have you seen the queries that the search code generates?)

But even the necessity of that is debatable. Do people generally search for nodes and users at the same time?

Drupal 7 location (Yeah, calling it 4.x would be a good idea, it breaks from a lot of the 3.x ideas) gets rid of the concept of node locations and user locations and goes pure fields-in-core. (err, assuming I got that working, I need to monkey with my local repo some more, it's been just sitting there for a couple weeks)

Long, long ago, (before multiple locations, I believe) there used to be seperate location_node and location_user tables.

The biggest question is:

"Will people want to be able to search across multiple locative fields in the same query?"

If the answer is generally "nah" then I see no reason NOT to just split up the location table completely and file the entire thing into the field. (this means that each field would get a completely seperate namespace)

Heck, if the answer is "yes" then we could just cache the coordinates centrally. Hmm, actually, only bothering to do that when someone puts together a view to do so would be doable (You'd take a storage hit and saving locations would be slightly slower, but it would allow esoteric views to be performant.

Or, I could PLAN for that but in reality stub it out with an error message saying something like "Congratulations, you just found a use case for a coordinate cache. Please describe your view at (issue id) and Bdragon will either implement the coordinate cache or give you an idea for getting along without it" ;)

Well, THAT was an interesting post for me to write. You made me give myself some ideas there ;)

hefox’s picture

hefox commented

"Will people want to be able to search across multiple locative fields in the same query?"

In d6 there's content_profile with cck field, ie the location is stored in a location cck field in a node for each user. (That's actually how I'm currently doing it on a site, because I prefer the control of content_profile, etc.). Ie, at least in d6 that use case can probably handled via content_profile. I doubt content_profile will have a d7 release with fields in core mm.

ankur’s picture

ankur commented
Version: 6.x-3.x-dev » 7.x-4.x-dev

Changing version to 7.x-4.x. Feel free to close if this discussion has concluded.