ewinslow wrote on 42365387-06-13

Some more options:

• Move some of these attributes to the entities table. name/description are common for every entity type.
• Move the attributes to metadata. The attributes are in their own table for performance reasons, but if we streamline metadata loading, this might be a non-issue.

Milestone changed to Long Term Future Release by ewinslow on 42365387-06-13

cash wrote on 42370249-04-18

Need to investigate adding a text field to every entity - what are the impacts to storage. Right now, I think every field in entity table is an int with fixed size.

I needed to query by attributes and I found this (official) way on engine/lib/plugins.php elgg_get_plugin_from_id()

$options = array(
'type' => 'object',
'subtype' => 'plugin',
'joins' => array("JOIN {$db_prefix}objects_entity oe on oe.guid = e.guid"),
'wheres' => array("oe.title = '$plugin_id'"),
'limit' => 1
);

$plugins = elgg_get_entities($options);

It looks simple, I am thinking about including a function elgg_get_entites_from_attributes (similar to elgg_get_entities_from_metadata)

I have a concern about how to handle the four types of entities, because every entity has its own attributes. Maybe validating attributes depending on type or write functions for every type of entity (elgg_get_objects_from_attributes, elgg_get_sites_from_attributes). I want to know this in order to write correct implementation and where to put the functions.

I think elgg_get_entites_from_attributes() should only query against one type table so validating by type will work.

Unit tests should look something like this: https://github.com/Elgg/Elgg/blob/master/engine/tests/ElggCoreMetadataAPITest.php (see testElggGetEntitiesFromMetadata()).

This is probably obvious but we should not take on a schema change for 1.9.

Definitely obvious. This is just about adding elgg_get_entities_from_attributes().