a little thinking about mORMot

畅雨 · 2013-10-27 07:11:18

Some time after the test :

1. Why is objectid not guid? If guid should be more Suitable for distributed applications.
2. SQL Parameters used '?' The SQL parameters are as follows: where (name like @p1) or (title like @P1) or （desc like @p1）,The parameters of processing need to write the same three, Why not use the parameter name?

ab · 2013-10-27 07:20:29

1. We followed the choice of SQlite3, which uses an INTEGER RowID column as default primary key.
In practice, it is very easy to work with, and efficient.
And it allows mapping to a pointer - which is used when defining One-To-One or One-To-Many relationships in the TSQLRecord via published properties.

2. We only implemented 'by position' parameters, for ease of implementation, and speed when parsing the SQL (lookup by index is much faster than searching by name).
You can use our TQuery wrapper if you do not use the ORM but just the SynDB* classes - it features parameter 'by name' - with fast hashing for search (so are much faster than the original TQuery.ParamByName method).

畅雨 · 2013-10-27 07:40:28

ad,Thank you for your answer!

1. I have been using instantobject,want to switch to mORMot, instandobject using guid as objectid...
2. I do not use the ORM but want to use SQL ans result as JSON,how to do it?

畅雨 · 2013-10-27 07:46:58

My idea is that rest API is not the ORM, but the definition of sql. Each rest API is defined as the execution of a SQL, and the SQL parameter is passed, performed by the DB layer, returned the JSON result to client.

ab · 2013-10-28 08:11:16

Take a look at the SAD pdf (in its 1.18 latest version), and its FAQ:
I am not a great fan of ORM, sorry, I still like SQL and have some experience of that. Some times sophisticated SQL query is hard to change to ORM code.
ORM can make development much easier; but you can use e.g. interface-based services and "manual" SQL statements - in this case, you have at hand External database access classes in mORMot, which allow very high performance and direct export to JSON.

See sample "16 - Execute SQL via services" for something close to what you need.
You can therefore bypass the whole ORM/CRUD/RESTful layer, and define your own high-level services, running your own SQL statements.
This is what is expected e.g. when you implement DDD services.

畅雨 · 2013-10-28 14:04:56

ok,thanks!

mpv · 2013-10-28 19:31:39

About GUID instead of Integer-based primary key: most database engine use sequence for primary key generation. And sequence is Integer by definition. Even MSSQL add sequence support in last version. So int-based primary key is very good choice IMHO.

ab · 2013-10-28 20:19:30

Indeed.

Another option could be to use a pseudo-random-increasing GUID, just like in MongoDB.
http://stackoverflow.com/a/5694803/458259
But it does make sense only with client-side generation, as in concurrent MongoDB creation.

mORMot Open Source

#1 2013-10-27 07:11:18

a little thinking about mORMot

#2 2013-10-27 07:20:29

Re: a little thinking about mORMot

#3 2013-10-27 07:40:28

Re: a little thinking about mORMot

#4 2013-10-27 07:46:58

Re: a little thinking about mORMot

#5 2013-10-28 08:11:16

Re: a little thinking about mORMot

#6 2013-10-28 14:04:56

Re: a little thinking about mORMot

#7 2013-10-28 19:31:39

Re: a little thinking about mORMot

#8 2013-10-28 20:19:30

Re: a little thinking about mORMot

Board footer