Decide if we can deploy field_collection on d.o for the D7 port of Project*

Uhhh. I don't know what you mean. It's D7 field API hell. It's a module for basically "fieldable fields". You make 1 field, on the parent entity, which is essentially an entity reference to a sub-entity. Then you can add whatever fields you want to the sub entity. So, for example, on a release node entity, we might have a field collection called "release files", which is multi-valued. This just points to a new entity that field_collection creates for us called "field_release_files". And then we hang whatever fields off of that that we need for each file associated with a release (a file field, download count, md5hash, etc).

Fields might not even live in a DB, so "the kind of queries that it produces" is sort of a meaningless question. Everything gets reassembled during entity_load(). That's The D7 Way(tm). You missed your opportunity to object to that about 2 years ago. ;)

Cheers,
-Derek

I think you need to spend more time with the internals of D7 to know what I'm talking about. Field API has pluggable storage. By default, every field lives in a separate DB table. However, you can swap out the storage such that all the fields for a given bundle (think "node type") live in a single DB table. Or, you could store your fields in MongoDB. Or any other crazy storage mechanism you want. The code isn't supposed to know how you're storing your fields.

Nothing about field_collection changes any of these fundamental aspects of how D7 fields work. All field_collection is doing is making it easier for me to assemble the fields and entities I care about to represent the stuff I need to represent. And it makes it possible for sites to extend the kinds of things Project* is storing just via the UI instead of necessarily having to write code for it.

But ultimately, the (non)performance of all the fields and entities is D7 core's problem. That's really a separate question. I agree that we should be afraid of how d.o is going to scale with D7 core fields. We're probably going to have to jump through a lot of hoops to make that work. But that's totally orthogonal to the question of if those fields are coming from the core field UI, if they're created programatically in Project*, if they're clicked together via field_collection, etc.

Just had an IRC chat with nnewton, killes, and timplunket. Summary:

• No one actually knows enough yet to be able to make an informed decision on if this is going to be a problem or not.
• The possibility that D7 field API is a performance nightmare for d.o is real, but more or less unrelated to whether we use field_collection or not.
• The performance hit depends a lot on the usage. Specific node pages (e.g. project/foo or release node/N etc) might be fine, but if we're trying to sort/filter based on things inside a field_collection, it could be worse. It's not just a question of how we store the data, we have to see how it's being used.
• We all agreed that starting with a relatively simple field_collection use case, building it, and then trying to assess how it actually behaves is prudent. So, we can't completely commit to field_collection yet, but we can at least move forward and see what happens. I think #1609382: Port release files with extra metadata to D7 is the best candidate for that.

So, that's the plan. I'll move forward with field_collection at #1609382 and then we can circle back and try to assess again once we have something real to test. For now, this issue is postponed...