Closed (outdated)
Project:
Devel
Version:
8.x-1.x-dev
Component:
devel_generate
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
8 Jan 2012 at 04:57 UTC
Updated:
21 Sep 2021 at 20:45 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
salvismoshe will have to look into this, but just a quick question anyway: Given the linked issue, will this perform reasonably if batchified, or will we still run into trouble even with the core patch?
Should we postpone this until the core patch is committed?
Comment #2
Anonymous (not verified) commentedre #1, i don't think we should wait. we can always adjust the batch size, but the point of this is not to make it fast, but to make it easy to work on patches like the one i linked to :-)
Comment #3
salvisYeah, I'm not so much worried about it being too slow, but about crashing, timing out, overloading the database, or exceeding the disk quota of limited accounts.
Any of this would cause us support issues that I'd rather avoid...
Comment #4
Anonymous (not verified) commentedi think we can address the crash and timeout issues with the size of the batch.
as for the rest - wait, what? how is this different from a bunch of the other devel generate commands that can do all of those things?
Comment #5
salvisI had a very cursory look at #1040790: _field_info_collate_fields() memory usage and got the impression that creating only a few content types would cause your database to explode, as long as the core patch hasn't been applied yet.
If that's the case, then we don't really want to provide a tool that will do just that.
Maybe I misunderstood the issue...
Comment #6
moshe weitzman commentedLooks commit worthy to me. Lets add the batching. Also, do we really need the menu_rebuild() call in the loop? Thats pretty expensive.
Comment #7
Anonymous (not verified) commentedattached patch adds batching.
Comment #8
moshe weitzman commentedLooks good. If someone could test this, that would be good. If noone does, I will get to it.
If we do a later reroll, FormAPI should be two words.
Comment #9
rodrigoaguileraI applied the patch and I I'm able to generate content types with the interface but I lose the overlay and no green succed message is shown.
via drush 6 beta 1 I get 2 errors
No hook functions were found for generate-content-types. The primary hook function is drush_devel_generate_generate_content_types(). Please implement this function. Run with --show-invoke to see all available hooks.
I renamed the function drush_devel_generate_content_types() to drush_devel_generate_generate_content_types()
and all other function names
and there is no menu_rebuild() anymore
http://drupal.org/node/1561492
I didn't fix the succeed message and the overlay issue.
Patch attached
Comment #11
pcambraComment #12
pcambraDevel generation has changed to be pluggable in #2154141: DevelGenerate as a D8 plugin type so this needs a re roll.
Comment #13
berdirI didn't know about this issue, but I wrote a quick implementation using the new plugin system to test some core stuff, see https://gist.github.com/Berdir/75041aaa46f391e844ac, feel free to use whatever you want from that... Currently only supports text fields...
Maybe we could use #2217481: Create a PluginManager for field types in devel_generate to also create new fields to have flexible support for widget/formatter and field settings?
Comment #14
willzyx commentedClosing for lack of activity. Feel free to reopen if the issue still exists