Eh? My concern is that the bit in some modules that creates a table if it doesn’t exist, and by checking the existence each time is therefore an extra hit on the DB here today with MODx as it is now.
If in the future, that is made redundant by some structure map declaration, then it seems even more like a good idea to move the SQL setup to a separate file, because such things wouldn’t be in the module/snippet. I am in favour of a separate set-up script because it gives a greater amount of flexibility right now - checking for a table, checking for older version of table to add new columns etc.
Unfortunately your post is one of those ones that fills me with dread rather than hope. What the hell is the persistence layer? Why should a data structure not be created at the point of install? What is the difference between an install/upgrade and the introduction of a new/revised structure map into the system? From the point of view of a non-techie installing a snippet through a WIZARD, would you not expect all required data structures to be set up during install - whether it’s by a script with SQL statements (or API calls, if you want to abstract things) or a part of xPDO acting upon a newly provided structure map? I can see that it duplicates a benefit from the future MODx, but as all I’m talking about is moving code from one script to another, I don’t see how it’s not worthwhile.
-
☆ A M B ☆
- 24,524 Posts
I think what Jason is saying is fine, on installation have a way to install any tables and whatnot. But there will be no need for checking every time the installed snippet/module/plugin is run, because it will automatically trap any errors, and at that point update or install whatever is missing and causing the error.
I don’t think it would be hard to implement this as an optional field int the "make new pakage" form. A resource creator can put raw sql code into this textarea. on form post, the content of that textarea will be written to a file called "mrw.sql". if the textarea value ="", no file will be created, and no reference to $resource_sql will be made in install.php. Paul, do you think this would work in your picture of where this is going (or should be going) .
@ All... suggestions and ideas are expected....
-sD-
Maybe I misinterpreted Jason’s "So I’d say this particular concern is really not an issue"; my post seems overly vicious in retrospect.
Yes, I think the .sql file is broadly similar to the future method of including a structure map, and I think it’s a simple solution to people’s needs right now. Raw SQL has one flaw though - it does not account for the db prefix. To be fair, some existing add-ons don’t account for it. Perhaps users should use modx_dbtable and then this could be replaced before execution.
I outlined a run-once script. I *also* like the idea of a separate run-once script, although I can’t actually think of a particular use for it right now. Maybe creating a folder or clearing the cache or something.
Where do I think this should be going? Well, I guess I just think that a Resource Wizard should be capable of wizard-ing as many installation steps as possible - making things as simple as when they are selected during in the MODx install.
I’ve not actually released anything that would be require a Resource Wizard yet, but the existence of this does make it more likely that I will. I know that large parts of this will be made redundant in the near future, but it is still a worthwhile exercise. Thanks to all concerned.
Or, if the content creator forgets and puts modx_whatever, it could come back and suggest the [dbpre] version.<br /><br />Have I tried this thing yet? No, and I’m going to shut up until I have, although if you want to PM me details of one with an SQL bit I might wrap up the AjaxPoll thing I did once.
MODX Staff
