It would help if I could get some clarifications for the workers side .
Apparently the code works well in the debug, then once I build the app the app stops working .
I assume that in debug mode it simulates the workers while on the build app it actually creates helpers.
Now, I do have an app that processes some files, the first part is ok, it works, where it processes the files.
The second part should connect to a SQLite Database and update some records , now, when reaching to this part the app stops, on some system debug logs I get that the app cannot connect to DB even if I included the DB class and modules in the project . I try to initiate the DB separate in the worker and it keeps on looping like crazy and does not work at all.
Seeing the docs and the examples , I guess you can pass only some data over the worker as string and thatâs about it, and only one time , so how do you manage multiple data processing ?
And as a side note @XOJO Team, it would be nice to have a Search on the top of the examples in XOJO, the new structure is a nightmare until you find something there.
You need to open your SQLite Database as multi-user WAL, so your main app and your Workers can all access it at the same time. By default a SQLite Database is single user only.
I started to put debug logs everywhere , so the code initiates the database then DB File becomes Nil so I assume that there is something fishy with the âProject Items To Includeâ part .
Perhaps something to do with permissions? (i.e. worker app processes when spawned from built app donât have permission to directory where SQLite database resides)
I think I found the problem, Apparently it does not like to have all the db in a global module that is of course embedded as well in the worker so I ended up moving all the code from Module to a class and now all works. I guess Iâll have duplicate code all over for each worker but as long as it does the job it should not be a problem.
@Xojo It seems that Workers are still not working properly in 2022R3.2 I did refactored my code in order to optimise little bit the app and now i get tons of errors that Modules apparently are not added or donât exist in Workers.
If i add the Documentation line
List of Project Items to include in the Worker Console app. No classes or modules are included by default. Enter one project item per line. To include all classes and modules, enter IncludeAllClassesAndModules .
Then i get an error saying that
ImportSource.Name
Project Item âIncludeAllClassesAndModulesâ in ProjectItemsToInclude could not be copied because it does not exist.
ImportSource
So it would be nice to have this sorted in the next release maybe as again i need to waste time to redo all the code and try to have it work, when it was supposed to work.
Robin will ask for an example project anyways. Could you make and add it to the issue?
Why would you add all classes and modules to the worker? Just asking for the use case. That would make the worker really big. Do the classes need to be console safe?
Why donât include all modules and classes automatically that are used in the workerâs code? This manually include thing makes using a Worker really complicated and error prone in larger projects. Xojo has all the infos to include, soâŠ
Because that would be very prone to error. If you have two similar class names and intended to use one but typed the other by mistake it would never spot your error. Surely it is better for you to declare your intent and be warned when something doesnât meet expectations.
That doesnât so much detect errors as allow you to see what is going wrong when it does. You would have to test everything very closely to know it was going wrong in the first place.
Itâs a bit like saying you donât want to have to declare variables because you can use the debugger to work out that you have a typo in your code using the debugger.
While it sounds simple, the reality is that youâre talking about a chicken and egg problem. âknowingâ everything thatâs used in a project requires a successful compile and compiling the project successfully requires only having console-safe components. The place where it gets trickiest is with subclasses, because theyâre not explicitly tagged as being console or not.
Besides, to keep the workers as small as possible, being explicit is going to give you the best result.
Again, Xojo (the compiler) has in the code all the information it needs, as Rick has already noted. Itâs more a matter of will Xojo provide such a tool to automatically create the dependencies for the worker, or do it silently in the compiler, for example. Iâm not saying this is âeasyâ, but it should be doable.
No, thatâs a totally different thing. Itâs just that Xojo does the work for us to detect the existing dependencies, which is what happens in the debug build but in a different context (desktop <> console).
BTW, errors along these lines will not display in the debugger, where Xojo is just using threads to simulate. In my experience, they will only throw when trying to build.
Youâre just not thinking this all the way through.
The compiler isnât involved at the point when the binary for the workers is being split off from the main project. Basically, the IDE creates a second worker-only project, compiles the worker, and then compiles the main project and incorporates the worker binary in the build.
