Any way to bulk update?
Permalink
I have a zillion blog posts I need to update the metadata on (meta title, desc, etc). I really don't want get carpel tunnel open each one... plus, I have utilities that manage that info in a very styrategicway, so the utilities need to update the DB directly.
I was looking in the directly and I thought I found the relationship between content and attributes, but I was wrong... and so far any attempt to do so has failed.
So my question is:
1) is there a standard way, or a utility, to bulk update content?
2) What is the relationship between all the necessary tables.. i.e. what query would list the metadata for each piece of content?
And while I'm here, can I also ask, why is there no referential integrity in the database schema? Does the lack of foreign keys almost guarantee orphans? And doesn't that make the whole object model much more heavy (in that the object login has to do more heavy lifting?)
Thanks
I was looking in the directly and I thought I found the relationship between content and attributes, but I was wrong... and so far any attempt to do so has failed.
So my question is:
1) is there a standard way, or a utility, to bulk update content?
2) What is the relationship between all the necessary tables.. i.e. what query would list the metadata for each piece of content?
And while I'm here, can I also ask, why is there no referential integrity in the database schema? Does the lack of foreign keys almost guarantee orphans? And doesn't that make the whole object model much more heavy (in that the object login has to do more heavy lifting?)
Thanks
nice. However, that bulk uploader still requires I manually type everything in. It does save me like 10 clicks for each update, but I am looking for almost an API kinda thing, or even a function that I can call from inside a C5 job that reads a CSV, for example.
Could I loop though the CSV array and call saveRecord with the values in the POST? Similar to the way it is done in concrete/single_pages/dashboard/system/seo/bulk.php ?
Could I loop though the CSV array and call saveRecord with the values in the POST? Similar to the way it is done in concrete/single_pages/dashboard/system/seo/bulk.php ?
We employ few foreign keys for a very simple reason: when concrete5 was first released, INNODB was slow and not widely available. We only just moved to require INNODB in 5.7.
So, sometime in the (near) future there will be foreign keys? Let me ask you, even though FK's were not practical I imaging they would have been useful at least for designing the schema. If that is the case, do to FK definition exist in any form? I'd be happy to build a tool that retroactively updates the tabes with FK.. not only for the performance boost but for the huge advantage that would be in writing my own utilities (ad understand how the DB is all put together)
No, there's no immediate plan to implement them. There are many, many features, improvements and bug fixes that have a higher priority.
I don't understand your second sentence. Obviously we have the "concept" of foreign keys throughout the database, and have had it since the beginning. Pages relate to Collections relate to CollectionVersions related to CollectionVersionBlocks relate to Blocks relate to each block's data table, etc... If we weren't able to require INNODB til 5.7 how could we have "used them when designing the schema" any more than we already have?
I don't understand your second sentence. Obviously we have the "concept" of foreign keys throughout the database, and have had it since the beginning. Pages relate to Collections relate to CollectionVersions related to CollectionVersionBlocks relate to Blocks relate to each block's data table, etc... If we weren't able to require INNODB til 5.7 how could we have "used them when designing the schema" any more than we already have?
It is not uncommon to design the schema before implementing it. I am referring the actual 'designing' part of the schema, not the actual instance of it. Or, maybe you have the ORM defined (again, on 'paper') even if you are not using it. I certainly understand that, as what you have now works, there are certainly higher priorities... but if you DID have a list of FK's defined (even if only as a byproduct of perhaps some tool used to design schemas) it would be super useful. I have a lot a FK's in my C5 database that I added (for performance and local utilities) because it was easy to see what they were, but I am sure there a lot that I have missed.
As for the lack of foreign keys, in 5.6 the db abstraction layer didn't really allow for it, but as the core migrates to doctrine objects in 5.7 they should be added.