mORMot Open Source

Hi,

I've been reading the (excellent) documentation from front to back, but I must have missed the following use cases.

I've got an existing applications using database that have lots of stored procedures. The choice of using stored procedures in most cases is quite logical:
  1. Performance of certain queries is just faster on the database directly that retrieving all the relevant data from the database and handling it in Delphi, like pivoting. In the documentation (5.4.2.1) sharding is mentioned as a solution for pivoting, but that won't/can't apply to (our) existing relational databases.
  2. Sometimes I need to use optimizer hints (ORACLE) to make certain queries more performant. (http://docs.oracle.com/cd/B19306_01/ser … ntsref.htm)

The fact that all SQL is auto-generated could in certain cases make data retrieval from the database using mORMot inperformant.
Is there a way of either overwrtting the generated SQL or specifying the SQL to be used, just for that specific TSQLRecord. I just want to expose the result of the stored procedure in JSON to the client.

Which brings me seamlessly to the second use case. I noticed the mORMot "auto-maintains" the SQL schemes. Is there a way of disabling that? As I'm working with existing databases, that might cause a lot of problems on ie. dataware-house ETL's. I don't the SQL scheme to automa(t/g)ically change without me knowing, as the implications might be cause unforeseen problems. I btw noticed a SQLAddField method, but where are the SQLRemoveField and SQLRename methods? It seems the framework is just adding missing tables and fields, nothing more. I consider that a maintenance horror as you lose control over your database schemes. I'm probably to use the TSQLRecordMappedAuto(Forced)ID, but there are no examples to be found on how to use these classes (if they still exist, because I couldn't find them in the source code).

In the documentation (6.2.3) the distinction between DTO objects and Domain Values is mentioned. I totally agree with the concept here, but if based on the same TSQLRecord class, how do you make the distinction? Consider the case where the client retrieves a TSQLRecord object (as a DTO object) from the server, that is made up from different distinct Domain Values. The client then changes some properties on the DTO object and sends it back to the server. Is mORMot able to get back to those original Domain Values in order to persist those to the database. Furthermore, in the examples, I never found anything that demonstrates the writing of a (Delphi) business logic layer. It seems that the Domain Model and the ORM layer are tightly glued together. In such a way, that is/seems hard to write business logic (like complex transformations etc) in between. (btw RemObject's DataAbstract suffers the same problem, they even force you to write that in Javascript).

Is there an example of one HTTP server with exposing multiple TSQLRestServer classes and/or interface-services, each with a different model?

One last (less important) question/remark: I was looking for a fail-over solution (as DataSnap offers). If the main application server goes down, the backup application server takes over automatically (on a different port). We found this very useful when updating application servers as it brings your downtime to almost zero.

Btw, the mormot.pas file is getting rather big. I'd suggest splitting that into separate (logical) units. Just my 2 cents.

Also some of the units are not compiling on XE3 (latest "trunk"):
1. mORMotBigTable.pas :[dcc32 Error] mORMotBigTable.pas(85): E2037 Declaration of 'EngineList' differs from previous declaration
2. SynDBUniDAC [dcc32 Error] SynDBUniDAC.pas(283): E2034 Too many actual parameters (This would have been my gateway to MySQL )

I've been trying to place everything into a package(s), but I only succeeded doing that with a subset of the source files (luckily the main ones). The others gave compile errors, mostly the GUI stuff. Call me old fashioned, but I'd prefer packages over source code in my library path. I just don't want to re-compile everything over and over again. The complete source consist of several different logical parts, they should even be in separate packages. When the source code was placed into the library path, all the demo's did compile however, but, as I said, not the preferred way to do things.

In other words, I'm just having a hard time applying the mORMot architecture to existing databases. Putting mORMot on top of an existing database and implementing the schema of page 68 in the documentation in practice, might be a great example series. I think I'm just missing that big-picture example, exploiting the full potential of mORMot.

Sidenote: any plans on moving to Subversion or git, making it more "accessible" to the big masses?

Kinds regards