mikak 2 Posted May 16, 2019 (edited) Hi, Started (again 😄 ) to examine how to convert our server from datasnap to mars. Our goal is to have api like /databasename/products or /databasename/orders/10 so one server should handle multiple databases which have same structure   To introduce every database Mars I write. for s in fdatabasenames do   FEngine.AddApplication(s+'-app', s, [ 'Server.Resources.*','customers.resources.*','orders.resources.*',..... {about 30 different resources}]); Is there approach ok? or does this waste server resources? one server should be able to handle 10-40 databases. Edited May 16, 2019 by mikak Share this post Link to post
Andrea Magni 75 Posted May 16, 2019 Hi @mikak, if you are looking to actually differentiate applications (i.e. different JWT secrets, different resources [apart from some shared ones], ...) this is the right approach.  If you are looking to expose the same API but target different databases according to the connected user, there may be easier approaches: 1) detect the user (enforce authentication and find a way to associate user X with database Y, store the association in the authentication token) 2) have a parameter (PathParam) in your resources (you can implement this in a base class and inherit your resources from that base class)  [Path('data/{name}')]  TDataResource = class   protected    [PathParam('name)'] FName: string;    property Name: string read FName;  end;  Then you can have your TMARSFireDAC for the proper connection name (you will define a connection each database in your configuration file).  I can be more specific but I am a bit in a hurry these days (more time next week I hope).  Sincerely, Andrea  Share this post Link to post
mikak 2 Posted May 16, 2019 Hi Andrea, Thanks for Reply. I'll study that path. About TMARSFireDAC... How much do I lose if I use UniDAC because FD with ODBC doesn't support trasnsaction savepoints (or nested transactions -can't remember correct term).  Thanks mika Share this post Link to post
Andrea Magni 75 Posted May 16, 2019 The MARS-FireDAC integration is nice to have but not strictly necessary. I would like to add other integrations to MARS with respect to other DAC libraries (Devart on top of course). Basically you can see these files: MARS.Data.FireDAC.pas ( https://github.com/andrea-magni/MARS/blob/master/Source/MARS.Data.FireDAC.pas ) MARS.Data.FireDAC.InjectionService.pas ( https://github.com/andrea-magni/MARS/blob/master/Source/MARS.Data.FireDAC.InjectionService.pas ) MARS.Data.FireDAC.ReadersAndWriters.pas ( https://github.com/andrea-magni/MARS/blob/master/Source/MARS.Data.FireDAC.ReadersAndWriters.pas ) MARS.Data.FireDAC.Utils.pas ( https://github.com/andrea-magni/MARS/blob/master/Source/MARS.Data.FireDAC.Utils.pas ) These is more or less all the implementation of MARS-FireDAC integration and it should be easy enough to replicate for UniDAC (I am not very experienced with UniDAC but I used it some time ago in a customer's project).  I would surely help if you decide to add UniDAC support to MARS. Keep in mind that MARS has a basic TDataSet support, so even if you do nothing you'll always be able to use UniDAC in the server and expose datasets as JSON through the standard (basic) default serialization as a JSON array.  Sincerely, Andrea Share this post Link to post