mORMot Open Source

thank you.
I didn't expected it to be SO trivial

I thought threads creation depends on number of requests (like FastCGI)

Hi,

first of all it seems the call to CoInitialize need to be done in Execute; method.
second of all, for some reason it need to be called for each request - otherwise I get the same error as previous on the second request (even though CoUninitialized is called in thread Destructor.)

are there any low-level tricks behind handling Request, which may cause this behavior?

once again,
1. CoInitialize is called at the very beginning of Execute; method
2. CoUninitialize is called in Destructor
3. calling CoCreateObject in the registered REST Server method works only for the first time - second call throws exception saying "CoInitialize was not called"
4. it works if I move CoInitialize to REST Server method...

any ideas?

I'm using TSQLite3HttpServer which, as I can see, tries to use THttpApiServer if possible, if not - it falls back to the higher-level ones.
That would require me not only to override methods in one class (HttpApiServer) but also the others (just in case the first one won't be used).
Not to mention the need to modify TSQLite3HttpServer in order to use "my" classes.

I wonder if there's any better "place" (method) to hook in thread creation?

yes, both are available.

Hi,
I'm very glad to see the latest Fossil version to use TMS optionally.
The code is mentioned to be 1.13 release, however I'm not able to found 'official' release - just the Fossil leaves - which don't contain sqlite3.obj ... could you please tell me where to download official release?

Thanks,
m

Hi,
I've modified the demo so it is compatible with current (as for 4 May 2011) sources from Fossil.
BTW where's the official release 1.13 available?

indeed. that's because I needed to implement very simple TSQLRibbon equivalent, but TMS-independent.
Removing TMS dependencies from UIEdit form was fast and easy, so I decided to create very simple general editor with grid preview on my own ... anyway, thanks for the tips!

Thank you I'll update the source and dig into it tomorrow

some thoughts ...

* FillOne -> at first, free all "related" objects (if they were created with FillOne)
* there should be a list of objects to free, so we won't confuse them with manually assigned objects.
* FillOne loads initializes all the 'related' fields with their instances
* each initialized instance is added to 'to-remove' list.
* there should be some 'guard' in order to protect from loading circual references.

Yes, that's what I did as for now - I did following:

    function GetFullName: RawUTF8;
published
    property FullName: RawUTF8 read GetFullName stored false;

/// ....

function TSQLPerson.GetFullName: RawUTF8;
begin
  result:= fSurname + ', ' + fName;
end;

which actually works, but is tricky - creates completely unnecessary field in SQL, also displays the field in UIEditor.

If I don't define my own unique field, ID is default one, right?
So, how about using ID as unique field for internal operations (storing it in ComboBox.Items.Objects casted to TObject) while for displaying create virtual method in TSQLRecord, called GetUniqueDisplayName - which could be implemented by user, or - if it's not implemented - just use first sftUTF8Text field?

from what I investigated the trick, it just changes the way it's written from PtrInt(fRoles.Dest) to fRoles.Dest.ID.

But still I have no direct access to the "real" Dest object, I need to create & later free it manually.

Let's say I have a TSQLLesson which has property Teacher: TSQLPerson.

to speed up development Id like to write code like this:

var
l: TSQLLesson;
begin
l:= TSQLLesson.Create(db, fLessonID);

ShowMessage(l.Teacher.Name);

correct me if I'm wrong but currently framework doesn't support it, I need to declare TSQLLesson.GetTeacher
which returns

function TSQLLesson.GetTeacher: TSQLPerson;
begin
result:= TSQLPerson.Create(db, Teacher.ID); // or PtrInt(Teacher);

and of course handling memory free manually.

Do you think it'd be possible to automate the object retrieval & freeing that way?

there's so much I have to learn about RTTI

yeah, indeed making that field unique is not the best idea ... but current way of handling automated relation edition makes it practically useless

Ok, I have changed the declaration to RawUTF8 on all the fields.
I'm using Delphi 7. And the problem still occurs...

actually the problem is reproducible on my sqlite-framework-demo which as you know doesn't require TMS.

I did so. I'm sorry, I was pretty sure you use svn So I didn't updated the source archives, just commited the lates version to svn

I don't get that, probably because I have absolutely no experience with web services in Delphi. Not even 'hello world'

ok, I'm looking forward to hear your proposals

To be honest, I prefer those most standard buttons and others components look, over the "glassy" look of recent Office interfaces.

that event handler is pretty good idea for a quick fix, but doesn't solve the problem in my opinion.

first of all, I think it'd be good to keep the logics separated from presentation layer, so the validation part should be done on the Record, not the editor.
Let's say I need to store IP address in a record, and I have pretty much ways of adding/editing record (for example, creating the new record directly or modifying it's data inside of a grid). No matter what "editor" I use, the "IP" fields still needs to be valid IP address.

From what I learned using PHP frameworks, automated data validation is very important and convenient. My suggestion is to expand TSQLRecord with methods like this:

//pseudo code

// run the validation of data
// implemented in TSQLRecord, 
// calls the GetValidationRules and check data against rules one-by-one.
// Validate method is called each time the object is about to be saved
// or is edited
function Validate(): boolean; 

// returns list of rules
// actually implemented by final (inheriting) class.
// each validation rule consists of 
// * field name to which rule applies, 
// * rule name or even better - rule class
// * rule additional parameters (string - JSON-formated? array of const? I dunno ...)
function GetValidationRules: TValidationRules;

// registers a callback to be called on validation error
procedure RegisterValidationCallback(CB: TValidationCallback);

// Field: field name 
// Message: message returned by validation rule
// FieldValue: proposed field value / field value after filtering
// AllowContinue: if set to true, it means there was no error in fact, the validator acts as a "filter" here (see below)
TValidationCallback = procedure (const AField: string; AMessage: string; AFieldValue: string; AAllowContinue: boolean)



example filters:
TRegexpRule:
 * checks given value against regexp provided as parameter. if it doesn't pass, do callback, with message "sorry it doesn't validate against regexp"

TToLowercaseFilter:
 * calls Callback with AAllowContinue = true and  AField = lowercase(OriginalFieldValue)
 this doesn't throw an actual error but ensures the field will be lowercase.

actually it might be wise to separate Rules from Filters, or give them separate callbacks.


implementation of GetValidationRules for my case would return array looking like this:

[['Email', TEmailRule, 'allowedDomains:.com;.pl;.eu;.us'],
['Userip', TIPRule],
['Userlogin', TLowercaseFilter],
['Userlogin', TStringLengthRule, 'minLength:5|maxLength:25']]

that is just an idea, I know many things might be hard to implement in delphi, they might not be optimal etc but hopefully I know what I have in my mind.

That way one would be able to simply define filters, expand filtering (creating own filters), handle errors (for example, when creating custom "editor" for the record, just registerValidationCallback and add labels containing errors for each field).

What do you think about it?

Hi,
is there any progress in making the Framework independent from TMS? I'm about to start a bit more serious project with Synopse Framework, as for now I can use TMS Pack demo I guess, but one day I'll need to make my app independent ...