Posted by fago on June 6, 2013 at 6:25pm
Here's the log of todays IRC meeting (Jun 6th, 16:00 UTC), #drupal-entity:
<fago> dixon_, berdir, das-peter, dixon_, effulgentsia, yched: so let's start? :-)
<yched> yup
<effulgentsia> y
<yched> hi everyone
<fago> hi :-)
so, topics to dicuss?
I'd suggest NG-conversion, fields, validation, ...
plach, translation?
<das-peter> tstoeckler: man, you scared me with your menu bundle question. I was already really afraid that we missed something :D
<fago> plach, ping :)
<tstoeckler> das-peter: lol
didn't know I had that power :-)
<plach> here I am
<berdir> so many people in here, scary :p
<das-peter> XD
<berdir> why aren't the conversions done yet? :p
--> dixon__ (~AndChat33@80.76.175.185) hat #drupal-entity betreten
<yched> SLACKERS !!!
<fago> :D
<plach> :D
<fago> speaking of that: https://drupal.org/node/1818570 is in!
<yched> berdir++
berdir++
<plach> berdir++
<fago> berdir+++
berdir, so next one is https://drupal.org/node/1983548 ? and files?
<berdir> druplicon isn't in here, so you can stop now .p
<fago> lol
<berdir> yes, contact messages, files and test entity
<das-peter> I guess menu links should be converted as well, right?
<amateescu> I have a starting patch for that
<fago> berdir, do you have the issue number of the test entity conversion? It's missing from https://drupal.org/node/1818580
<berdir> http://drupal.org/node/2004224
that's everything outside the field api tests, extracted that because it passes (needs a re-roll now) and is 50% of the patch
the other one is http://drupal.org/node/1822000
that will need a major re-roll after the previous issue is in
<-- dixon_ hat (Ping timeout: 264 seconds) beendet
<fago> berdir, do we need both for being able to refactor field API to use NG api?
<berdir> yes
but I'm not sure about a lot of tests in field api
there are a lot of field attach/field storage tests that will need to be rewritten somehow I guess
yched: ?
<yched> well, "field API to TypedData" patch is mostly blocked on field type tests
<das-peter> amateescu: a starting patch for the menu link entity conversion?
<amateescu> das-peter: yep
<yched> those are included in the RTBC patch
<das-peter> amateescu: awesome! Do we have an issue for that too?
<yched> the tests about Field API itself (field_attach...) are not blocking
at least, not blocking me :-)
<plach> https://drupal.org/node/1842858
das-peter: ^
<das-peter> plach thanks!
<amateescu> yeah, my patch is not posted yet
but if you guys want I can do it now
<berdir> yched: ok, but they will have to change to be able to remove the bclayer /legacy stuff
<plach> yched: speaking of that one, I suspect we have BC decorator issue there (sync tests)
<yched> plach: so yeah, that :-)
plach: actually I think the fastest approach would be to rewrite FieldSync directly on EntityNG
will need to bet done at some point anyway
<plach> yched: also, I gave a quick look to the patch and I think it might clash with/benefit from https://drupal.org/node/1810370 (not really sure :) )
<yched> and it seems the best route to fix those pesky fails in the "field to typed data" patch
<fago> yched, plach: yeah, I guess it has to change a bit as the concept changed from having $langcode on entity level instead of field level
<yched> fago, plach: I actually started to work on that (field sync on NG), will post a separate patch soon - doesn't pass yet
<fago> yched++
<yched> plach: would you be willing to take over from there ? :-)
<plach> yched: sure, but to rewrite field sync we need all NG conversions done, I am afraid :(
<effulgentsia> only fieldable ones, right?
<plach> and I think what's triggering the BC decorator issue is something in the test not actually the syncing logic
effulgentsia: sure :)
<effulgentsia> plach: https://drupal.org/node/1983548 is the last one
<berdir> and not relevant for translations
<fago> yched, so for auto-create + validation: we can set $entity->ref->entity = $new_entity; with entity-ng and then on pre-save just save referenced entities being $entity->isNew() - but that would only work for converted entities then...
<plach> cool, ddin't realize that
<berdir> test entity however might be, against what entity type are the tests written?
<plach> then we are good
:)
<yched> plach: I don't think so - the test uses an NG entity. we just state "field sync only works on NG entities",voil& :-)
<fago> effulgentsia, this one and test entity :/
* berdir wonders what happens if you add an image field to a contact message o.0
<plach> yched: we'll see, anyway I can take that one over, but I0d really wish to focus on entity dotrage asap
* entity storage
<berdir> I'm going to re-roll contact message and the first test entity issue tonight, reviews/rtbc's would be great there
<tstoeckler> berdir: afaik nothing actually :-)
<berdir> tstoeckler: probably ;)
<plach> I need to get in touch with chx I guess
<fago> berdir, yeah, I'll review after the metting
<effulgentsia> lol. i was wondering if "dot-rage" was some new irc slang i wasn't up on.
<fago> plach, definitely, he is into the unification issue but not really into simplifying the enttiy-storage internal logic I think
lol
<yched> yeah, going afk in 10-ish days, I'm not sure I'll have the time to look into entity storage much :-/
<berdir> also, reviews on the file entity conversion would be important as well
because that's the first with a real interface and methods and shows where we want to go I think
<fago> yched, do you think we should have / need entity validation for the initial field conversion patch?
<berdir> I think a lot is already done there?
<fago> yep, it is. but I'm not sure we have to include it into the first patch, do we?
<plach> yched: I had the secret hope that field sync would "just work" with NG entities, I guess it doesn't, right?
<yched> plach: me too, but nope :-)
<plach> big troubles?
<yched> plach: dunno yet? Fails, but couldn't investigate yet
<plach> issue number?
<yched> plach: https://drupal.org/node/2013837 (just created it)
<berdir> fago: I will try to tag the relevant issues including blockers for ng conversion & bc removal, so that we can have a separate page for that in rocketship, I think that would help
<plach> yched: thanks, I will staty tuned :)
<yched> fago, berdir: yes, field validation on top of NG validation mostly works
<fago> berdir, yep, that would be great
<yched> aside from the fixes from https://drupal.org/node/2012662 that are a pain to carry in the patch
<plach> berdir: yes, please!
<berdir> fago: suggestion for a tag name?
<berdir> How are we going to attach http://entity.worldempire.ch/sanity ?
<fago> yched, I see - great! What was the remaining problem with field validation I wanted to look into? Sry, I even forgot what it was about :(
<plach> berdir: lol
<berdir> attack, I mean, in which order :)
<effulgentsia> yched: once you go afk in 10 days, when will you return?
<fago> berdir, Field API NG blocker ? It blocks conversion of field api to use ng ?
<berdir> fago: ok
<-- GaborHojtsy hat (Quit: GaborHojtsy) beendet
<yched> effulgentsia: post july 1st :(
<yched> fago: the issue I mentioned in Portland is fixed, stupid mistake on my side
<fago> berdir, @typed sanity: I think moving metadata methods out should be last, primitive to interfaces first and remove TypedDataInterface in between. The others don't require a special ordering I think
yched, great to here!
<plach> (ot) has anyone here an idea of what happens to issues that are bound to code freeze but that are blocked on stuff that is going to be finished post-code-freeze? are they screwed?
<yched> fago: what's blocking me on the validation side is https://drupal.org/node/2012662, and some e_r autocomplete widget refactoring, seen with berdir and amateescu
<berdir> fago: sounds sane ;) any chance you'll be able to start with the primitive interface thing?
<amateescu> plach: I would say it depends on thresholds, but with a higher chance on the screwed side
<fago> good question... I guess it depends
<effulgentsia> plach: what do you mean by bound to code freeze? do you mean they break apis?
<fago> dixon__, are you still on the primitive interface issue? :-)
<dixon__> I'll try to tackle some typed sanity
<plach> I have some stuff in ET that needs to be converted to fields but I cannot do that until all fieldable entities are NG, and I think entity NG work has been explictly mentioned as stuff that is not bound to code freeze
<dixon__> Yeah I'll continue where I left off from during drupalcon
<plach> effulgentsia: ^
<fago> dixon__, great! Just ping me if you run into any questions
<dixon__> fago: sure thing
<berdir> plach: what exactly is blocking? because all non-test fieldable entity types are ng now...
<fago> yched, ok, I'll help to push this one forward
<plach> berdir: well, translation metadata can be attached to any fieldable entity, including test ones (and yes they are test-covered)
<fago> plach, is it using test_entity or just entity_test? entity_test is fine. entity_test vs test_entity - yeah!
<dixon__> guys, I'll have to leave. But I'll do my best to move forward with typed data sanity stuff
<plach> fago: yeah, entity_test :)
<berdir> plach: then you should be good
<dixon__> I'll be in the queue and on irc more regularly moving forward :)
<plach> yep, I just realized that :)
<berdir> dixon__: k, looking forward to some patches then ;)
<fago> dixon__, great! bye
so speaking of typed sanity, https://drupal.org/node/1868004 would need reviews
<-- dixon__ hat (Quit: Bye) beendet
<berdir> fago: will try to look at that after I re-rolled my issues ;)
<fago> berdir, thx!
<berdir> das-peter: http://drupal.org/node/1758622 likely needs a re-roll now to incorporate the validation stuff, do you have time to work on that?
<effulgentsia> fago: can you update the summary on that one. it seems to explain the problem, but not the solution.
<plach> do we have an issue to deal with ->target_id vs ->value quirks?
<das-peter> berdir: I'll give it a try. ;)
<fago> ok, so let's talk about validation? Initial entity validation for the test entity got in just today: https://drupal.org/node/2002152#comment-7505677
effulgentsia, indeed, I'll do
so we can move on with converting existing validation logic to constraints now, for entities that are already NG
<effulgentsia> plach: what are the problems with ->target_id?
<fago> meta issue is: https://drupal.org/node/1696648#new
<berdir> fago: can you start with a change notice there asap? would help with crowdsourcing the other issues I think as it's not trivial to understand at the moment
<effulgentsia> plach: in general, nothing should assume that ->value is special. it's just a commonly used name.
<fago> berdir, sure, just did not have time for it today yet.
<plach> effulgentsia: this is the current situation, and it's causing some troubles, I think I discussed it with berdir somewhere but I cannot find the issue
<fago> berdir, turns out we do not have a single validation change notice yet
berdir, I think I'll do that and then a blog post also, maybe some people are interested in helping out here :-)
<berdir> fago: also not sure what's the next step there. we need the map-violation-to-form-api stuff soon I think, so that we can actually remove the existing form validation functions for e.g. node
<tstoeckler> bye, bye everyone. keep rockin'!!!
<berdir> fago: sounds good. Yeah, I had a feeling that we're missing some change notices there ;)
<fago> berdir, yeah. So what I've been wondering here is how we deal with form error messages - is it ok if they change to a certain degree? At a minimum we'll have to work over the message generated right now and make sure they fit
<yched> yeah, messages need some care :-)
<fago> e.g. required right now only results in a "This value should not be null." messages... :D
then for improving test coverage of constraints, I think we should a first unit test for a single constraint + create issues for others + try to crowd source as well
<yched> This value should be of type 3 :-D
<berdir> yched: interesting....
<fago> yched, lol, 3 is a constant - everyone knows which one of course :D
<yched> berdir: https://drupal.org/node/2012690
<berdir> obvious! ;)
<yched> fago: what I'm doing in my patch is that my constraints specify their custom t()ed messages
<yched> (field constraints)
<effulgentsia> fago, yched: is the problem that constraints have no api for violation messages to reference the field name/title?
<yched> right
so, ^^
<fago> yched, how do you do that? You should define it as a message property on the constraint class, are you?
I see
<yched> fago: the message can be injected along with the other settings
<yched> 'Length' => array(
'max' => $this->field->settings['max_length'],
<fago> yched, exactly
<yched> 'maxMessage' => t('%name: the text may not be longer than @max characters.', array('%name' => $this->instance->label, '@max' => $this->field->settings['max_length'])),
)
<fago> yched, but it shuold not go through t() at that point, it runs through t() later on
<yched> hmmm.
<fago> yched, we implement the TranslatorInterface and pass a translator for that to symfony validator
<yched> hmm, that might be a problem
<fago> yched, not sure whether we can add replacements here...
<yched> coz I can inject a message string, but not additional replacements
other than the ones defined in the constraint class
<effulgentsia> DrupalTranslator::trans() accepts parameters
<yched> or at least, I couldn't figure it out
<fago> effulgentsia, that's being called from the ExecutionContext - addViolation() - which is called from the constraint validator. This one provides the replacements params
effulgentsia, yched but that's generic per constraint ...
<yched> no
<fago> yched, ?
<berdir> not if you want a message that is actually english I guess. like a URL/an integer things
<yched> well, not if we want to differ from hardcoded templates in symfony constraint classes
<yched> fago: how do I do "%name: the text may not be longer than @max characters"
<yched> ?
I think the messages+placeholders should b entirely up to the code that adds the constraint, not tied to the constraint class
<fago> yched, true, but it isn't :( As said, the placeholder values are controlled by the constraint validator right now
<-- amateescu hat (Quit: Leaving) beendet
<yched> fago: well, if we have no hope of changing that (custom placeholders),
<fago> yched, I guess we could add in some fixed replacements by doing a custom executioncontext class, but still it would not be overridable by the constraint
<yched> then I guess we must prepend "%name:" ourselves, when displaying errors in the validated form
that's a bit of an issue for me, because I have a mix of new-style constraints and old style hook_field_validate() errors
<fago> yched, that would be definitely the simplest solution - if it's feasible? :/
yched, so we need to convert the old-style errors over also?
<effulgentsia> the constraint class $message properties are public and not static. so they should be settable on a per-constrain basis.
<yched> the latter generate messages with the %name: prefix
effulgentsia: $message works, yes
but not adding new placeholders+values
<fago> yched, I guess it would be great if one could add placeholder values on it also
<yched> fago: I'm not sure it's really i18n friendly
<yched> I mean, force-prefixing "%name: " in front of translated error messages
<fago> yched, yes - you would not be able to change the pre-pending for other languages any more
<effulgentsia> yched: right, but ExecutionContext has access to getMetadata()
<yched> fago: right
<berdir> Ok, I also have to go... will be uploading a few patches tonight :)
<fago> berdir++
<yched> right now, t(%name: @value is wrong) can be "lala @value lolo %name blip"
<effulgentsia> yched: so, if we can set the constraint's $message to "lala @value lolo %name blip", and then swap in a DrupalExecutionContext that is able to pass along those extra parameters to trans(), we should be good, right?
<fago> yched, so we could override ExecutionContext to look into the constraint and check whether it has add place holder values also? It's a bit weird though as constraints are supposed to be defined up-front....
effulgentsia, yep, but from where does it get the extra placeholders?
<-- berdir hat (Ping timeout: 248 seconds) beendet
jygastaud hat (Quit: Quitte) beendet
<effulgentsia> fago: isn't that what getMetadata() is for?
<effulgentsia> on ExecutionContextInterface
<fago> effulgentsia, you can derive the typed data object via that, but that would be field_text.0.value not field_text - which has the field label
effulgentsia, and when we remove typed data interface we'd have no generic way to go up a typed data tree either
<yched> (I would also vot to be able to pass custom error codes - many Symfony validators call addViolations() without specifying an error code)
<fago> yched, yep. I guess we should reach out to webmozart and talk about those issues
<yched> " you can derive the typed data object via that, but that would be field_text.0.value not field_text - which has the field label"
<effulgentsia> fago: the validator itself is a graph walker: can't it go up the tree to the field?
<yched> but the extra placeholders and their values could be specified by the code that sets up the constraint ?
<fago> effulgentsia, It can only go down the tree, right now
<effulgentsia> or, maybe what yched suggests is even better and simpler
<fago> yched, yep, I'd see it working that way also. As mentioned, it's just a bit weird that you have to set run-time information in $constraint which is supposed to be "configuration"
effulgentsia, yeah, I think having a way to pass any placeholders into it at run-time is reasonable
<yched> well, it's "how it should fail when it fails" ?
<plach> yched: empty patch in the helper issue :)
<fago> yched, it would not be a problem in our case as we generate constraints for a field on the fly anyway? Or at least we can massage them before passing them on
yched, I don't see a better solution anyway.
<yched> plach: doh - wrong git command. thanks !
<yched> fago: yep, works for me
<effulgentsia> fago: are we up to date on the Validator component? seems like we might want to get the latest of that before implementing a custom DrupalExecutionContext to support this.
<yched> other than that, care for a more general status info on the "field / typed data" issue ?
<effulgentsia> i'm interested
<yched> so, all previous hooks are covered except
field_attach_prepare_view()
field_attach_prepare_translation()
plach: is the latter on it's way out soon (D6 translation model) ?
<plach> scratch the last one
yep
<fago> effulgentsia, we've not updated it for a while. Yeah, maybe it would make sense doing it upstream even
<plach> it will go away with the legacy translation module
<yched> plach: coll - but it's still called / tested right now, no ?
s/coll/cool/ :-)
<fago> yched, I talkd to gabor about it shortly and he thinks it might have to stay as profile.module does due to upgrade path issues
<yched> oh
<plach> yched: I guess so, I don't remember excactly
<fago> yched, not sure whether this means we have to continue supporting it everywhere, what would suck a lot
<yched> but I guess we can stop supporting this on the field side ?
<plach> I guess we could simply remove it along with its test
<yched> fago: do you have an issue # for that ?
<fago> yched, I really don't know.
yched, nop, just talked to gabor on the sprint
<yched> I'll try to grab gabor
ok, other than that
<fago> yched, k
<yched> hook_field_load() --> FieldItem::prepareCache() works
but
currently breaks the optim of only creating FieldItems when strictly needed
last time I looked, it was a bit complex, I need to dig further
the prepareCacheInterface thing we talked about in portland
next, field data purge is going to be a bit tricky
it still works right now because the old hook_field_delete() implemetations still exist, and it calls them directly
<fago> yched, so prepareCache() creates the object for all non-configurable fields, or for configurable ones that are already cached also?
<yched> fago, oh, right, there's that too
<yched> right now it's a bit muddy
field cache currently is just config fields
<fago> sure.. :/ there is an entity cache issue but it got stuck being over-engineered
<yched> curently we call prepareCache() on any FieldItem that implements it
right, so, not sure how we move forward here without de-facto introducing an entity cache
<fago> or better said, it wants too much at once :/
yched, yes - I think that's the only sane approach with the new storage anyway. But I guess that should be post-poned on the storage issue?
<yched> well, I don't know how to postpone only that part without postponing the whole patch
which would be mighty risky...
<effulgentsia> yched: do we need an entity cache in order to have prepareCache(). can prepareCache() still run, and just not result in being cached?
<yched> effulgentsia: hmm. tricky
in the current patch, field_attach_load() does:
check cache
for the entities not found in the cache
load from storage, invoke prepareCache, put in the cache
<fago> yched, yes - I thought that is what we are going to do also? There shouldn't be any non-configurable fields using prepareCache() right now, because we don't have it for them right now :D
<effulgentsia> yched: oh, so we still have the field cache. can we keep using that until we replace it with an entity cache?
<fago> yched, so we check for the interface, if not there - skip it
<yched> fago: yes, would work I guess
<yched> also, the problem is that the interface would be at the FieldItem level
<fago> yched, effulgentsia: entity cache issue: https://drupal.org/node/1596472#new
<yched> but we typically invoke methods on the Field, and it typically defers to calling each FieldItem
<fago> yched, true.. but we can get the class from the field definitions and check the interface there without instantiating it
yched, I think we'll need some helper for that + interface checks anyway
<yched> fago: we can. it means we put a prepareCache() method on ConfigurableFieldBase no matter what, that calls the FieldItem prepareCache() ?
<yched> but only actually call Field::prepareCache() if FieldItem implements prepareCacheInterface ?
<fago> yched, hm, then we'd already instantiate the field class.. I'd just check it via the definition and if it's there invoke it on every item ? possibly on field level also
yched, or just do it for the field level and make an alternate field class that you can use then?
<yched> fago: sure, 1st check whether the item class, check for preparecacheInterface, only then invoke it
<yched> but I'd rather avoid field types that need a prepareCache to be forced into a specific Field class
<fago> yched, so check it on the field class, invoke it and then in the field class check it for the item and if so and invoke them?
<yched> fago: no, I was thinking: put it in ConfigFieldbase() no matter what
<yched> then at runtime, check the item class, if implements preparecacheInterface, then call Field::prepareCache
hmm
<fago> yched, but then I could place custom prepareCache login into the field class and it won't be invoked...
<yched> then again it's odd; "check the interface of class A, then call the method on class B because we "know" it will internally defer to class A"
<fago> yched, exactly, that's why I'd rather check A invoke A, check B invoke B
<yched> fago sure it will, I call TheRightFieldClass::prepareCache()
<yched> which means it needs to be in an interface anyway...
<fago> yched, but you call it only if the field item implements the interface?
<yched> ... right ... less and less convinced :-)
<fago> yched, but if it doesn't but the field does, the field is not called? So my logic in my custom field class would be skipped without notice
<yched> right
<effulgentsia> fago: what's the use case of Field having prepareCache() logic that's anything other than delegate to field items?
<yched> in portland we considered we could go with not supporting that
"prepareCache() is only item by item"
<fago> effulgentsia, I don't know, but if the Field implements the interface it tells me (as average developer not knowing the internals) that I can do my prepareCache() stuff in there if I want do - but I can't
yched, effulgentsia: then maybe skip it on the field level at all, and invoke it directly on the items from the storage or from wherever it gets invoked
<effulgentsia> fago, yched: i think it's worse dx though to make text fields use a different Field class.
<yched> effulgentsia: agreed
<effulgentsia> fago: we could do something like...
<fago> effulgentsia, indeed, that sucks also. So invoke it directly on items?
<effulgentsia> if Field class implements prepareCacheInterface, call it no matter what. if it doesn't, but field items do, call it directly on the field items.
<yched> fago: well, EntityStorageController::invokeFieldMethod() currently only does "call the Field, let it deal"
<yched> mixing that with a special case on prepareCache that iterates on items instead is :-/
<fago> yched, we could add a invokeFieldItemMethod() alternative though?
effulgentsia, yeah, but as said we don't care about $field implementing it, so we could skip that part?
<yched> fago: invokeFieldItemMethod: yep, probably the best plan. We need some special logic to iterate on fields without instanciating the FieldItems anyway
<yched> 'k let me write that down somewhere :-)
<fago> :-)
<yched> next item :-)
<fago> >One thing I'm not too fond of is the fact that we standardize placing constraints in getFieldDefinitions(). This data is persistently and statically cached, this bloats memory with validation info, that is not relevant for 95% requests.
<yched> reminds me of something :-)
<fago> I'm not sure it's really so much that it is an issue? it's there only for base fields and there should not be much as most constraints can be type defaults or generated, e.g. for allowed-values. So I guess it stays with 1 per field
then, where else put them?
<yched> separate method only called when validating ?
<fago> yched, it kind of is the case for field API fields already also - e.g. text field max length is in the field settings and always loaded, although mostly not needed
<yched> fago: well, only kind of
<fago> yched, method on what? It's per base field "instance", not type.
yched, where is the difference?
<yched> it's a "setting". we don't know which settings are used when, so we store them in one place
<yched> fago: but right, as long as we only do that for base fields, the overhead should be fine
<fago> yched, true, what means it's even better we could optimize caching to not cache the constraints or cache them separately if we'd be up for it?
yched, what would suck is if we end up with setting + constraint, so if there is a setting we need to generate the constraint of course
I guess the meeting sort of ended and moved to discussion already :-)
<yched> fago: as long as Configurable fields generate their constraints at runtime, based on their definition, then fine
<yched> I'm afraid I did that :-/
(hijack the meeting, I guess)
<effulgentsia> what else did you want to cover, fago?
<fago> yched, it's fine that way I think, we've gone through all the topics we brought up
I was just mentioning :-)
we did not talk about translations though... plach, are you still around?
<plach> fago: I'm leaving in 5 minutes
<fago> ok, do you want to shortly talk about entity translation status or talk at another time?
<plach> currently I'm working on https://drupal.org/node/1810370
which should let us simplify entity multlingual logic quite a bit
<fago> plach, oh great, so how does it go? Does it make EntityNG class very complex?
plach, I guess we could simplify it more once EntityBCDecorator goes away. right now, it sucks that we cannot re-arrange protected $values due to the BC-decorator using it
<plach> not really, it adds a some methods and a couple of object members so far
in turn it blows away the EntityTranslation class :)
everything uses the the plain entity object
the other big issue on my list is entity storage: I'd really wish that stroage for every field was under the entity system control
since it's only way to ensure multilingual is always taken into account
<fago> plach, well, field storage is already multi-lingual by default anyway?
<plach> yup
my concern are non-configurable fields
<fago> plach, yes, but simplifying doing multi-lingual base field storage is really important I agree
<plach> exactly
my end-goal would be of having storage-agnostic entities which should be feasible if we are allowed to perform efq conversions after code freeze
technically they should not be API changes
<fago> plach, true
<plach> we just need to separate generic logic and storage-specific logic before that
which I believe is what chx is working on, right?
<fago> plach, exactly
plach, he's already a patch up for it
<plach> cool
<fago> plach, https://drupal.org/node/1893772#new
<plach> I'll get in touch with him
yched: do you think you'll be around the field to entity storage issue?
<yched> will try, but afraid not :-/
<plach> fago: yep, already following that one, just too busy with the ET API stuff
<yched> before July 1st is hard
<plach> yched: ok, I'll try to do what I can then :)
<yched> patch traffic jam :-(