mORMot Open Source

It won't affect the mORMot code itself, but it affects we users of mORMot - because we might use both of those units.

Using a unified, short prefix for all types is a best practice that's been proven, to prevent existing and future conflicts.

As a strong example, If we use TSynTextWriter instead of just TTextWriter, it won't have been conflicted with System.Classes.TTextWriter.

Yes, we shouldn't use a prefix that's too long.

My initial feeling is that, isn't mORMot follows the Active Record pattern? Then maybe record is easier to be understood?

Sorry, but it's still not clear to me if I can pass a RawUTF8 string to the AddLine method? It compiles, and is it really OK? Thanks!

@ab,

A little issue with using the methods on the client side:
- Called ServiceRegister then ServiceDefineSharedAPI, mORMot will complain about 'interface already registered'.
- use ServiceDefineSharedAPI only mORMot will complain about 'interface not registered'.
- Use "TServiceFactoryClient(ServiceRegister(...)).ParamsAsJSONObject := True" will cause  access violation

Not sure why. had to use the following code instead:

  svcFactory := (Services['ApiForClient'] as TServiceFactoryClient);
  svcFactory.ParamsAsJSONObject := True;
  svcFactory.ResultAsJSONObjectWithoutResult := True;

What happens if the master server is down during the process of syncing? Can it persist the pending data and restart the syncing?

PS, I remember I posted a similar reply yesterday but somehow it disappeared...

This thread is useful. For the same requirement (backward compatibility), I had to gone further than you #4 option - I resorted to method-based service - everything is JSON and you'll have to process it.

Not sure about earlier versions of OneDrive, but recent versions of OneDrive is just like Dropbox, it's not a virtual drive but only a sub-folder of another physical drive such as D:\

I might didn't describe it clearly, but these kinds of issue only happens on occasional db files at occasional times - it not always happen. So yes, I can open those db files with other sqlite db file viewer, because the issues don't happen all the time.

Have you looked at this: https://www.yunqa.de/delphi/products/converters/index

Thanks for the comment, ab, I forgot about that :0

But I guess it's better if mORMot support escaping, for example, '\%' won't be treated as a parameter.

This thread is a good read, thank you guys! The systemd socket activation is really interesting, the start-on-demand nature is similar to that of the 'serverless' (eg, AWS lambda) hype.

Not sure if Window server has the similar feature?

Do you mean after the db's compressed, it'll become readonly?

Is there any way to ask the original SQLite author for help?

It seems to be a good thing if mORMot get sponsored!

@Vitaly,
Alternatively you can use TStrings/TStringList as the published property type, you'll get JSON format in the db, and it doesn't have the 'CreateCopy' issue described here.

But when being stored in the db, a field of type TRawUTF8DynArray is not in JSON format? Persisting in JSON format is required in my use case.

After some debugging I wonder it might has something to do with TSQLPropInfoRTTIObject.CopySameClassProp?

I see, thanks.

Please be noted that fpcx64mm is **also for Windows** under FPC.

Great! Just discovered it earlier.
It seems that there is a major change in licensing. I assume one can use the GPL license in a closed-source, commercial program?

@ab,
I looked at the code in TSynLog.DisableRemoteLog, but such approach doesn't seem will work in my case, because my 'SMTP remote logging' works like this:

1 - My EchoCustom will not directly send the log entries but just push them to a TSynQueue.
2 - Then another thread will pull from the log queue and send them through SMTP one by one.

The exceptions happens in step 2 is what I want to ignore by TSynLog.

IIRC, some of the NewPascal features have been merged into the FPC trunk?

Thanks for sharing your migration experience! What "remote logging" mechanism are you using? I'm recently thinking of logging from mORMot to sentry.io.