Leaderboard

Hi @Stuart Clennett, you can add the IsReference attribute to instruct MARS not to free the object returned by the method (as it will be destroyed within the datamodule of course, as it is its owner). [GET/POST, IsReference] function GetAssessment(const id: string): TFDDataSet; Sincerely, Andrea

Hi @Stuart Clennett, I am happy you found a way to solve by yourself while I was in vacation 🙂 Your solution works but has a couple of things to consider: 1) that BeforeHandleRequest code gets executed for each incoming request (performance) 2) manipulating Parameters is not suggested as App.Parameters is like a global object (IIRC). You have an other opportunity through (yet another) undocumented MARS feature: [Context, Connection('Dynamic_MyConnection', True)] FD: TMARSFireDAC; The Connection attribute specifies the name of the connection definition to be used with the TMARSFireDAC instance injected. The name supports macros (the second argument enables macro expansion). You can rely on built-in macros (i.e. using some part of the token, params, username or similar things. A list is available here: https://github.com/andrea-magni/MARS/blob/a8d323558bd591589ef667eac326324302d167a9/Source/MARS.Data.FireDAC.pas#L528 ). Last chance of the macro-expander is looking for custom providers. You can register your own in the initialization of one of your units or in the Server.Ignition.pas file: TMARSFireDAC.AddContextValueProvider( procedure (const AActivation: IMARSActivation; const AName: string; const ADesiredType: TFieldType; out AValue: TValue) begin if SameText(AName, 'Dynamic_MyConnection') then begin if Odd(SecondOf(Now))then AValue := 'OddConnection_' + AActivation.Request.HostName else AValue := 'EvenConnection_' + AActivation.Request.HostName; end; end ); Beware: the connection name has to be this format: [PREFIX]_[SUFFIX](_[OTHER_SUFFIX]) Using 'MyConnection' won't work for instance... Pros of this approach: 1) code is executed only when needed (when the TMARSFireDAC instance gets created to be injected in your resources), all others REST endpoints won't be affected. 2) it seems more isolated to me (but this can be a personal evaluation). If you need to fix some TFDConnection instances on your datamodules, try having a TMARSFireDAC instance injected in the datamodule itself and use the FD.ConnectionDefName (already expanded once injected) to fix the ConnectionDefName of your components (OnCreate event of the datamodule should be fine, or AfterConstruction method as well). If you encounter troubles doing this, write here again: there's another hidden feature for you to fix this (when registering the datamodule as resource you can specify an anonymous method to initialize it or to call a custom constructor instead of TDatamodule.Create(AOwner)). Sincerely, Andrea

I think there is never a good reason to tolerate unit dependency cycles; they are a consequence of bad design. Again, if you do not see why unit dependency cycles should slow the tools, there is much of the internal action of the IDE which you do not appreciate. As Anders Hejlsberg said in the video I cited earlier, "...as soon as you type a character, you have broken the code." That is meant no literally, but in the sense that any new character in a code file provokes rebuilding of parse trees. It's good that you are getting your feet wet. I have been developing tools to address these issues for the last couple of years, not as a pet project, but a part of my current employment, and I assure you, it is not nearly as simple as you seem to believe.

As to the class constants, I must assume it is a defect in the IDE which is tied to the parser used for code completion. In my comments, I did not say that the tools do not work; I did identify factors which affect performance. There may well be other strategies which might be applied to avoid the issue with search path, but I consider it poor practice not to name all your own units as members of the project. Unit dependency cycles are a whole other issue. I can suggest you watch Anders Hejlsberg's video on modern compiler construction. Or just consider with a whiteboard what happens with a small collection of units (A, B, C, D) when: A uses B, B uses C, C uses A and B uses D, but D uses A and B. It's a mess, and when you consider a larger application, the mess is multiplicative. If you see no reason for the result, I submit you may have spent little time understanding the process. I have spent a number of years dealing with legacy code in large projects, and untangling things is a challenge.

I've read many complaints about speed and stability of the IDE. And I have made many such complaints. But in fairness, I have seen in large legacy projects that there are many things we can do which undercut the performance of the IDE. For example: Leaving units out of the DPR, relying on the search path. Slows code completion. Declaring const field members in a class. (D2007) Breaks code navigation below that point. Accumulating unit dependency cycles. Slows IDE response, but also slows the compiler on full builds. There are other "thoughtless coding tricks" which may also contribute to poor behaviors, but those three are big. Also, how many third-party components have you installed? Are they all solid and stable? That has been a risk area since D1.