#1 Re: Delphi » GetIt.RealName := 'GetItIfItWontHurtOurSells' » 2015-06-10 19:12:28

I find it a bit strange that all just start by having a negative attitude. They clearly state that you are welcome to contact them with questions and/or just try to submit. So I suggest you ask them if mORMot would qualify and if the answer is No then I am sure that I and many others will gladly join in complaining.
If on the other hand the answer is Yes, we don't have to waste energy complaining up front.

As to the "spirit of licensing and editions" I think it is fairly obvious what they are referring to. They don't want to put anything on GetIt that would cost them any significant amount of sales. It has nothing to do with your or mine Delphi end-user license terms as far as I can see.

#2 Re: mORMot 1 » interface contract check » 2014-11-17 15:02:31

This is a great suggestion! I hope it will get implemented.

#3 mORMot 1 » Best way for a service to return blob data » 2014-04-29 07:32:15

Replies: 1


What is the best way in mORMot to return blob data from a Rest service?

The clients will be either Delphi or Ajax and once the data has been received they will store the blob data as a file. On the server side I have the data in a TStream or in a DB field.

My current idea is to use RawByteString like this:

  procedure GetBlobData(const DataID: Integer; out FileName: string; out Data: RawByteString);

If possible I would also like to compress the data in a way that both client types can handle, but I have no idea how to do that....

Pointers are welcome :-)

br Lars

#4 mORMot 1 » Non-framework error/result handling with services as methods » 2014-04-28 13:01:25

Replies: 1


I have been looking a lot at the mORMot documentation lately as well as making some demo projects. I think it is a great framework! and have started to use it in one or our projects.

I am focusing on the "services as methods" side and not the ORM/DB. I will need to create 3-6 "services" interfaces and each of these will have from 10-50 methods.

I am trying to figure out a good common error/result reporting "mechanism" to use consistently for all these methods.
By error/result reporting I mean how you return information about the method call to the caller. Not errors in the framework, connection etc.
e.g. a method like

  procedure AddProduct(aID: string; aName: string; aType: Integer);

could result in errors like:
- Invalid ID/Name/Type
- Product already exists
- Not allowed

My current idea is to use a "generic" record for all methods. Something like

  TCallResult = packed record
    Error: Integer
    Severity: TSeverityEnum;
    Text: string;

  procedure AddProduct(aID: string; aName: string; aType: Integer; out Result: TCallResult);


  function AddProduct(aID: string; aName: string; aType: Integer): TCallResult;

- Is this a "good" way to implement it or is there a better way (maybe part of the framework)?
- Is using the "out" parameter better/worse than using a function with the record as the result?

br Lars

Board footer

Powered by FluxBB