mORMot Open Source

I agree with MichaelR. I have seen people putting db backup files in the very same db... (not for a long time of course ;-) )
If a system allows for such things, people will do.
You really should have a rather good reason if you want to put such big files in a db otherwise they should be stored elsewhere.

will do

Hi,

ab, if you're going to extend on this topic, I also have a feature request...

Dynamic arrays and Records are serialized into binary format when they're published properties of any TSQLRecord descendant when that's stored in a db. That's fine and is working nicely. But, when time comes one might have to extend a type and then the already stored records in the db are no longer compatible to the new record type and can't be deseriealized any more to the new version of that type - which is understandable...

While e.g. TDocVariants are serialized into json in a db record field, (since those don't have an explicit structure), you can simply introduce new fields in such types. But here I don't have compile time type checking of course.

For me ( and maybe others... ? ) it would be of great help if it were possible to have a global or per TSQLRecord or per Field configuration option for record and dynarray serialization in public properties of TSQLRecord descendants.That option should force serialization in json format instead of binary format. Then deserializing such record would be possible even if the type of the record has changed. (Like it is possible by manual calling RecordLoadJSON and using the soReadIgnoreUnknownFields option). My main point here is not the serialization format but the possibility for schema evolution and I think going for JSON format would be the easiest way...
Of course I could define custom serialization formats per record but this leads to a lot of handwriting which potentially can be done automatically. And since your enhanced usage of RTTI for 2010++ versions of Delphi I started to throw out all of the record registration calls...

Also I could use TCollection/TCollectionItem descendants as a record alternative everywhere. Sometimes that makes sense, sometimes not. DynArrays/Records often make more sense. I just have the problem that when Record Types change, then I have do convert existing DB-Content before it's usable with the changed Record Type.

What do you think?

Martin

I am using the latest nightly build and register the server with the following code:

    fServer := TSQLRestServerDB.Create(FModel, ChangeFileExt(paramstr(0), '.db3'),True);
    fServer.CreateMissingTables;
    fServer.ServiceRegister(TAuftragsbearbeitung,[TypeInfo(IFuseAuftragsbearbeitung)],sicSingle);
    fHTTPServer := TSQLHttpServer.Create(PORT_NAME,[fServer],'+',useHttpApiRegisteringURI);

The client is created as follows:

  fClient := TSQLHttpClient.Create('localhost', PORT_NAME, FModel);
  fClient.SetUser('User', 'synopse');
  fClient.ServiceRegister([TypeInfo(IFuseAuftragsbearbeitung)], sicSingle);

SmartMS 2.0.1 build 741 has been released on 18.03.2014. Don't know yet if that fixes the problem...

Thank you, great. That gives me enough reason to use RawUTF8

Excellent.

Thank you.

Hi,

I think this is some kind of a more general topic.
Are there best practices about how to change an existing model?
I understand it's easy to add new TSQLRecord descendants and extend a model that way.

But when I need to add an additional property to an existing TSQLRecord descendant and at the same time want to continue using the already existing underlying db, how do I do that?

The same problem arises if I want to change a property name... or a Class name of a TSQLRecord descendant.

If I decide to write a migration program that could convert an existing model to a newer version of that model, other problems arise:
I can not have different versions of a model at the same time in the same program which would be necessary to read from the existing db and write to the converted db.

I am asking for the best general aproach of how to do such evolutionary conversions. Since changing a model without loosing existing data is a common scenario, how have you dealt with that in your own projects?

Changing the db manually? Would be possible I guess, but that would somehow be a real break of the ORM Idea. Is there some kind of way doing it in object pascal code? Spending quite some time with the documentation and the forum I haven't yet found anything specific to this topic.

kind regards
Martin