We have separated all the queries into different classes, to be compiled later. We still have a lot of troubles, it's not enough.
We are compiling all classes one by one using a loop and "ru" flags, and when the compiler stops we fill in the CompileAfter statement with the class which is not found. After that, we move to a new namespace and start again (because results depend on what is also semi-compiled, we need to start from scratch). This is the only method which seems to reduce the number of errors. Though we need to do it programmatically. We found that there is also embedded SQL code in methods which has dependency needs (and cannot be moved) also, it seems that relatioships definition expect to find the referred class already compiled. In addition it seems that ##class(xxx).Method calls create a dependency to class xxx too. At present we don't know how to solve circular references, for example if Class_A has compileAfter=Class_B and Class_B has compileAfter=Class_A the compiler refuses to go on. This happens if Class_A has an &SQL embedded statement which refers to table B, and class B has to call a class method of class A, for example. But if we could have some documentation about what can cause dependency and what doesn't, it would help us a lot. We're asking ISC support. It is mainly a deployment problem: during the development phase, since classes are developed one by one, it doesn't appear. When we are ready to deploy the classes to an existent namespace, and rebuild all..surprise, it's impossibile! Max "Max Sebastiani" <[EMAIL PROTECTED]> ha scritto nel messaggio news:[EMAIL PROTECTED] > Hello Bill, hope you're fine! > The fact is that I don't know if the queries are the only cause of troubles, > certainly they are, though it's a lot of work to move them, and perhaps it's > not enough. > > Sometimes it seems that we find the class which is causing troubles, we cut > it into pieces, moving SQL code apart, and later in the sequence of > compilation, hoping that it solves, but then the compile error appears in > another class, which has no SQL at all. > > So, if we knew what is certainly causing a dependence (generally speaking) > in Cache, and what not (method, properties, SQL, etc) we could start > thinking about which piece of code needs to be separated. > Doing this by trial and error is a mess... > > Is it possible to get this information from developers ? > > TIA > Max > > > "Bill McCormick" <[EMAIL PROTECTED]> ha scritto nel messaggio > news:[EMAIL PROTECTED] > > I think this is the only real answer here Max. If the trouble is coming > > from Queries in the classes then the easiest solution would be to move > > them into a separate package. Compile your class package and once that > > completes then compile the Query package. > > > > Max Sebastiani wrote: > > > > > Hello again! > > > > > > > > >>I would suggest you use the following format for $system.OBJ.Compile: > > >> > > >>Do $system.OBJ.Compile( class, "bruy" ) > > >> > > > > > > > > > ,,we have been using "r-bkvu" until now, and also tried a lot of > > > combinations, no results. > > > > > > > > >> From the documentation (Do $system.OBJ.ShowFlags()), "b" will compile > > >>subclasses; "r" compiles all classes that are dependency predecessors; > > >>"u" avoids compiling up-to-date classes (albeit as you say sometimes you > > >>need "f", the opposite); and "y" finds dependencies within SQL (and I > > >>don't remember seeing that one before!) > > >> > > > > > > > > > The "y" is something new, I really need it! Our problems are 99% with > SQL. > > > Although I just tried, no visible changes to the results (with 5.07). > :-( > > > > > > I'm thinking about moving all our queries apart, into different classes > > > which somehow will be compiled later. But it's a disaster, we have about > 150 > > > of them... > > > Also, having good tests is difficult, we always have to start with an > empty > > > database, or the tests will be influenced by what we have compiled > before. > > > > > > I understand that it's a complicated issue to solve for ISC, but a > compiler > > > which doesn't know how to compile its classes is a big limitation for OO > > > enterprise projects. We need to scale to about 1000 classes by the end > of > > > the year, and now I'm seriously starting to worry about it. > > > > > > Max > > > > > > > >
