- Add Drupal\field\FieldInfo as a 'field.info' service in field.services.yml

- Go over the FieldInfo class, collect all its service dependencies (entity manager, module handler, state...), add them as __construct() params, and as parameters in the yml service definition.

- Provide friendly access to the service through a Field::fieldInfo() static method
(discussion about the exact name of the helper class is taking place in #1961548: [Policy, no patch] Decide how the module-specific services are made available as static methods (similar to \Drupal::$service()), but that's not a blocker to get this started)

- Replace calls to _field_info_field_cache() by Field::fieldInfo(), and remove the function.
No need to remove the other field_info_*() functions for now, we'll remove them progressively.

Files: 
CommentFileSizeAuthor
#9 1950088-follow-up-9.patch945 bytesandypost
PASSED: [[SimpleTest]]: [MySQL] 54,804 pass(es).
[ View ]
#6 field-info-service-1950088-6.patch13.21 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 54,915 pass(es).
[ View ]
#6 interdiff.txt809 bytesswentel
#4 field-info-service-1950088-4.patch13.25 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 54,738 pass(es).
[ View ]

Comments

yched’s picture

Title:Move FieldInfo class to the DIC» Move FieldInfo class to DIC

Moving this to the core queue.

Having a Field::fieldInfo() method available soon would let us replace a large amount of the field_info_*() calls while we go over code that accesses $field and $instance definition structures in #1953408: Remove ArrayAccess BC layer from field config entities.

Would also provide a landing place for whatever comes out of #1953414: Move logic of field_read_fields() and field_read_instances() to the storage controller..

In short, it would be a good time to do this :-).

Any takers ? :-)

yched’s picture

Issue summary:View changes

Added task summary

yched’s picture

Issue summary:View changes

unclutter

yched’s picture

Title:Move FieldInfo class to DIC» Move FieldInfo class to the DIC
Project:D8 Field API» Drupal core
Version:» 8.x-dev
Component:Code» field system
Priority:Normal» Major
Issue tags:+Field API

fix title

yched’s picture

Title:Move FieldInfo class to DIC» Move FieldInfo class to the DIC
swentel’s picture

Status:Active» Needs review
StatusFileSize
new13.25 KB
PASSED: [[SimpleTest]]: [MySQL] 54,738 pass(es).
[ View ]

Let's see how this behaves

yched’s picture

Yay !

Nitpicks :-):

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -1,20 +1,22 @@
  * A Drupal\field\FieldInfo object is created and statically persisted through
- * the request by the _field_info_field_cache() function. The object properties
- * act as a "static cache" of fields and instances definitions.
+ * the request by Field::FieldInfo. The object properties act as a

"statically persisted through the request by Field::FieldInfo".
Not really. Maybe skip this entire paragraph ? I don't think other services bother explaining their relation to the DIC and helper static methods.

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -33,6 +35,27 @@
+   * The cache backend to use.

Do we really need the ".. to use" prefixes ? Sounds a bit boilerplate.
(same in __construct() phpdoc)

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -33,6 +35,27 @@
+  protected $cacheBackend;

Similar use cases in core use both $this->cachebackend or $this->cache, but the latter seems a bit more common.
Brevity++ ?

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -33,6 +35,27 @@
+   * Stores a module manager to invoke hooks.

Maybe just "The module manager." ?

swentel’s picture

StatusFileSize
new809 bytes
new13.21 KB
PASSED: [[SimpleTest]]: [MySQL] 54,915 pass(es).
[ View ]

Yeah, I basically copy/pasted a lot from the Views class - which why it went relatively fast and exceptionally worked on a first try :)

New patch, only removed the paragraph for now, maybe a follow up to make sure both classes are standardized ?

yched’s picture

Status:Needs review» Reviewed & tested by the community

Works for me.

webchick’s picture

Priority:Major» Normal
Status:Reviewed & tested by the community» Fixed

Once again this looks like fine DX-cleanup, but please don't mark these patches as "major" when they're simple refactoring.

Committed and pushed to 8.x. Thanks!

webchick’s picture

Issue summary:View changes

Update issue link

andypost’s picture

Status:Fixed» Needs review
StatusFileSize
new945 bytes
PASSED: [[SimpleTest]]: [MySQL] 54,804 pass(es).
[ View ]

There's a test that now gets random failures

Settings are changes in child process and entity_info_cache_clear() has no effect on field_info_cache

Berdir’s picture

I've actually seen this happening in other tests as well, fixed that at least twice.

What I did was simply adding a field_info_cache_clear() above it and say "clear the cache" instead of skipping it. While that's a tiny bit slower, it's a typical pattern in tests I think.

swentel’s picture

Is this still valid, I'm pretty sure the random failure wasn't introduced by this one, so I think it's valid to close this no ?

swentel’s picture

Status:Needs review» Fixed

I'm going to close this, talked this through with alexpott as well. Ran the test 70 times with --repeat option and no single failure. We have seen it before the move to a service as well.

If there are random failures, file a new one, it's easier to keep track than follow ups.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

andypost’s picture

andypost’s picture

Issue summary:View changes

bolder changes