Anyone on here used it - any comments pointers in how to use etc

Roy Lambert

Roy,

You have to slog through their 800+ pages of documentation which includes a few tutorials. It is not the easiest db to learn because you need to change your mindset to an object oriented model. Its tables are best suited to being accessed via a single key value, but it does have some SQL Select capabilities. You access your data via classes that you construct for it, which can be incredibly powerful and fast. I looked at it but did not spend enough time to do anything useful with it.

https://github.com/synopse/mORMot

If you decide to delve into mORMot, we might not hear from you again. You could blow a much needed neuron, go stark raving mad, or get to love it. So I should warn you. "Should you or any of your mORMot team be caught or killed, we will disavow any knowledge of your actions. Good luck Roy."  ..... Pfffsssttt.

Barry

Barry


Thanks for the answer.I've just spent the last couple of hours searching the web for pros and cons for ORMs and I've come to the decision that the best approach is to run away screaming wildly.

Roy Lambert

Roy Lambert wrote:

> Barry
>
>
> Thanks for the answer.I've just spent the last couple of hours
> searching the web for pros and cons for ORMs and I've come to the
> decision that the best approach is to run away screaming wildly.

It is my decision too. I have a friend who uses a lot of such things,
and his code seems quite fragile to change. "Let's add a new value to
the JSON I pass in", I say, and I add the line to write it and read it.
His code then blows up due to an undefined field, or due to a missing
field when I haven't made the changes yet. And it seems to require
complications on SQL tables that I don't like the sound of. Me, I need
a new field, I add it, I read/write the value to JSON or SQL, and I add
a suitable field to the table. I so fear I may be missing out on
something, but so far I have survived without it.


--

Matthew Jones

Matthew,

As far as I can tell, mORMot has no EDBMgr equivalent so I don't know how someone would alter the structure of an existing table without writing a Delphi program to do it. After all, mORMot can handle different data types (classes) than Sqlite so a Sqlite mgr won't be able to handle the restructure.

If anyone is interested in ORM, maybe they should look at TMS Aurelius first because they have better documentation. If they can digest that, then may look at mORMot.

Barry

Barry,

I should have been clearer - my colleague writes web servers in C#, so
I have no idea what it is he uses, but the backend is SQL Server. It
was simply the ease by which adding a new parameter, or leaving one
out, gets me a 500 server error that was worth commenting, since it all
appears to be down to his ORM. It maybe that he could make it more
flexible but I think he likes being tight on parameters so there is no
GIGO problem.

--

Matthew Jones

Barry

>As far as I can tell, mORMot has no EDBMgr equivalent so I don't know how someone would alter the structure of an existing table without writing a Delphi program to do it. After all, mORMot can handle different data types (classes) than Sqlite so a Sqlite mgr won't be able to handle the restructure.
>
>If anyone is interested in ORM, maybe they should look at TMS Aurelius first because they have better documentation. If they can digest that, then may look at mORMot.

One of the things that put me off was the fact that all the articles / blogs I found were referring to SQL only and I still use a lot of table navigational stuff. Then even ORM's supporters were saying that for performance you frequently had to go down to writing the SQL yourself since te ORM would generally produce SELECT * type statements.

The final killer for me was that everyone implied that you need database enforced RI for ORM and I have this love hate relationship with RI. No, sorry, I'm not being strictly honest, I just hate database enforced RI!

Roy Lambert