Search the Community
Showing results for tags 'easydeploy'.
Found 4 results
macjos posted a file in Samples
22 downloadsBeing unsatisfied with solutions I found on the internet and wanting a solution without plugin I created a set of custom functions that can read a path out of a json-string. Syntax: json_path ( json-string ; path ) examples: json_path( $user_prefs ; "Privileges/Modules" ) json_path( $json_data ; "Menus/Menu/MenuItem/Label" )
Joshua Willing Halpern posted a topic in FM EasySyncHi, I have a db ~27Mb. Using EasyDeploy As Is takes very long to complete (~20 minutes). Each segment takes around 10 seconds and there can be anywhere 90 to 300+ depending on the $segment_size. I modified the EasyDeploy file by adding a table occurrence for the hosted file's EasyDeploy table and then replacing the script's loop with a simple Set Field that copies the B64 data from the host's field and decodes it locally into the container field. The new wait time is < 1 minute. Soooo... My question is why use this looped Get (ScripResult) method instead of simply grabbing the data through a relationship and then closing the EasyDeploy file when done? I have a hunch it has to do with Tim wanting to abstract the process as much as possible but I'm not sure. Maybe a relationship has other consequences? Josh
Hi Tim, I was wondering why you seemed to have backed away from deleting the EasyDeploy file once it has been used, and instead set a flag "consumed?" Did you feel that the "Export Empty to delete a file technique" was not reliable? Also, at the top of the Upgrade Solution script in the EasyDeploy file, you have an Installer OnTimer Script [Interval: 0] script step. That might be a left over from attempts at a 1-click update, because I do not see any previous OnTimer sets. Can you confirm? Thanks, Barbara
folks posted a topic in FM EasySyncIt seems like it would be possible, in the interests of maintaining a single code base, to configure EasyDeploy as a single database that could be renamed and the appropriate EasyDeploy layout container filled before deployment. That is, there is a server and client EasyDeploy table, they are different but with no similarly named fields so they could be combined perhaps. Likewise, with the EasyDeploy layout fields in both could be combined into a single layout. Deployment would start with a database where the helper file is in the appropriate EasyDeploy layout container. This is the client file. Copy the client file and call it the server file. The client file is added to the server file in the appropriate EasyDeploy layout container. The helper file can be removed from the EasyDeploy layout container in the server file, but likely will not cause any problem other than making the server file larger if it is left in place. Hopefully I have not missed an infinite regress in this merging process… Any comments are most welcome. Thank you,