TvPlanIt fixes

[DonAlfredo]

I will try to reproduce !
And report back.

Until that time, you can try the release (project1static.exe) to see how easy the mORmot works, if working  ... ;-)

[wp]

I had fiddled around with the field mappings a few days ago, but obviously forgot some fields.
These are the changes made so far:

Events:
- PlanIt field "AlarmWavPath" is called now "DingPath", like in DB. Old name still accepted.
- PlanIt field "Note" is called now "Notes", like in DB. Old name still accepted
- New field "Location", same name as in DB.

Contacts:
- PlanIt field "Note" is called now "Notes", like in DB. Old name still accepted.

I did not really look carefully enough whether the old names are still working. I'd appreciate if somebody could test with old database files.

I'll take care of the others soon.

[EDIT]
Done.  Here's a list of all changed PlanIt field names

 Resource:
    Active --> ResourceActive
 Contact:
    Position -> Job_Position
    Note --> Notes
 Event:
    AlarmWavPath --> DingPath
    Note --> Notes
    AlarmAdv -> AlarmAdvance
    AlarmAdvType -> AlarmAdvanceType
    CustInterval -> CustomInterval.
    Location (new);

[DonAlfredo]

@JD

Try this change in mORMot.pas (around line 19266)

procedure SetID(P: PUTF8Char; var result: TID);
{$ifdef HASINLINE}
{$ifdef CPU64}
begin // PtrInt is already int64 -> call PtrInt version
  result := GetInteger(P);
{$else}
begin
  {$ifdef VER3_0}
  SetInt64(P,result);
  {$else}
  SetInt64(P,PInt64(@result)^);
  {$endif}
{$endif}
{$else}
asm
  jmp SynCommons.SetInt64
{$endif}
end;

procedure SetID(const U: RawByteString; var result: TID); overload;
{$ifdef HASINLINE}
{$ifdef CPU64}
begin // PtrInt is already int64 -> call PtrInt version
  result := GetInteger(pointer(U));
{$else}
begin
  {$ifdef VER3_0}
  SetInt64(pointer(U),result);
  {$else}
  SetInt64(pointer(U),PInt64(@result)^);
  {$endif}
{$endif}
{$else}
asm
  jmp SynCommons.SetInt64
{$endif}
end;

Remove these lines in RESTData.pas (last lines):
   TTextWriter.RegisterCustomJSONSerializerFromTextSimpleType(TypeInfo());
   TTextWriter.RegisterCustomJSONSerializerFromTextSimpleType(TypeInfo());

[DonAlfredo]

@wp ...   IMHO, still some pending fixes in vpflxds.pas !

First.

Line 1113: FN := GetFieldName(FEventMappings, 'ResourceID');
Here, the fieldmapping for ResourceID is looked up in EventMappings.

But, in the next line: if (FN <> '') and FResourceDataSrc.DataSet.Locate(FN, Resource.ResourceID, [])
this mapping is used to locate something in the resource dataset, that should have used its own mapping.
Correct line 1113: RFN := GetFieldName(FResourceMappings, 'ResourceID');

Same valid for:
Line 1539

Second

The code in function TVpFlexDataStore.GetFieldName is not that ok IMHO
result := '';
if Mappings.Count = 0 then
   Result := VpField
else

The above means that, even if you only want to map a single field, you have to map all fields !!
Lost of works and lots of CPU cycles !
I would do:
result := VpField;
if Mappings.Count > 0 then
begin

Again, see my previous commit (vpflxds.pas ) :
https://github.com/LongDirtyAnimAlf/mORMotPlanIt/commit/09e43e2ea2c4473d8d5ae6502f077aaae1e9d387

[wp]

DonAlfredo, thanks for the explanation. I was confused because the top of your diff was not related to tvplanit directly, so I postponed it for a quiet hour.

Agreed with issue #1.

Headache with issue #2: It causes trouble with my newly introduced field "Location" which is not available in my test DB. All the code within vpflxds compares the return value of GetFieldName with an empty string to know whether a PlanIt field is available in the DB. With your solution, however, GetFieldName never can be empty. This means that all PlanIt fields must be present in the database. This seems to be a severe restriction for a "flexible" datastore. Why should the DB contain all the spare user-defined and custom fields if the final application does not need them?

In the new version of GetFieldName I am using your proposal but override the result if the field is not in the DB:

Code: Pascal  [Select][+][-]

1. { returns the name of the dataset field currently mapped to the   }      
2. { specified internal Visual PlanIt field. If not field is mapped, }      
3. { then it returns the Visual PlanIt field name, but if the field  }
4. { is not available in the database it returns an empty string.    }
5. function TVpFlexDataStore.GetFieldName(Mappings: TCollection;
6.   VPField: string): string;
7.  
8.   function FieldAvail(AFieldName: String; ADataset: TDataset): Boolean;
9.   begin
10.     Result := ADataset.FieldDefs.IndexOf(AFieldName) > -1;
11.   end;
12.  
13. var
14.   I: integer;
15.   FM: TVpFieldMapping;
16. begin
17.   result := VpField;
18.   I := 0;
19.   while (I < Mappings.Count) do begin
20.     FM := TVpFieldMapping(Mappings.Items[I]);
21.     if Uppercase(FM.VPField) = Uppercase(VPField) then begin
22.       Result := FM.DBField;
23.       break;
24.     end;
25.     Inc(I);
26.   end;
27.   // Make sure that non-existing fields are identified by an empty string
28.   if ((Mappings = FResourceMappings) and not FieldAvail(Result, ResourceTable)) or
29.      ((Mappings = FContactMappings) and not FieldAvail(Result, ContactsTable)) or
30.      ((Mappings = FEventMappings) and not FieldAvail(Result, EventsTable)) or
31.      ((Mappings = FTaskMappings) and not FieldAvail(Result, TasksTable))
32.   then
33.     Result := '';
34. end;

[DonAlfredo]

Thanks and agreed.

But I think that the extra code again consumes much wasted cycles.
Wasted, because the field-setup is non-changing within a program.
But I do not know of anything better, besides generating lookup tables.


However, a small proposal for non-existing fields: map them to an empty field !

Code: [Select]

with TVpFieldMapping(EventMappings.Add) do
begin
    DBField:='';
    VPField:='Location';
end;


[wp]

the extra code again consumes much wasted cycles.

I agree that the code does waste processing time, in particular because the GetFieldName is called many many times. But on the other hand, it this really a limitation that you see in practice?

proposal for non-existing fields: map them to an empty field

Hm... Your previous proposal reduced the size of the mapping table, in many cases to zero. But this one blows it up again filled with lots of empty strings. In total, I think not much is gained compared to the current repository code.

If the present code really poses a speed limitation (but I doubt that) the datastore should get access to sorted lists of table field names for binary search. But I think I'll postpone that until the major issues are done.

Currently I am fixing the alarm sound. Then, I think, printing and print preview will be left. Since I don't find any information on these: Does anybody know how to call the print preview for the PlanIt components?

[DonAlfredo]

@wp: all ok !
@JD: the FPC 3.0 issue of mORMot is fixed !
http://synopse.info/fossil/info/744bbee51fb5caca81522b2b60912ec0a684ff13

[JD]

@wp: all ok !
@JD: the FPC 3.0 issue of mORMot is fixed !
http://synopse.info/fossil/info/744bbee51fb5caca81522b2b60912ec0a684ff13

@Don Alfredo & @wp. Thanks to both of you for your hard work. I'll give it a retry ASAP.

JD

[d.ioannidis]

Hi Alfred,

@JD: the FPC 3.0 issue of mORMot is fixed !
http://synopse.info/fossil/info/744bbee51fb5caca81522b2b60912ec0a684ff13

just tested mormot 1.18.2745 with fpc 3.0.1 ( fxes 33982 rev. ) in windows 10 64bit code page 1253,
with command line  "-Twin64 -Px86_64 -CpATHLON64 -MObjFPC -Scaghi -CX -O2 -XX -l -venibq -vw-h- -Fi.. -Fifpc\x86_64-win64 -Fu.. -Fu. -FUfpc\x86_64-win64 -FEfpc\x86_64-win64\ -CpCoreI -CfSSE3 -OpCoreI -OoFastMath" .

These tests fails, 

2.7
  Service oriented architecture - Test over HTTP

2.9
  External database - SynDBRemote

2.10
  Windows API

2.11
  DDD shared units - User CQRS repository 

2.12
  DDD multi thread - Single client test
.

FPC and mormot starting to look a very, very, very promising duo ...

EDIT: I generated the TestSQL3FPCInterfaces unit with Delphi 7, and fixed the double occurrences of the mORMotDDD unit and to add SynLog unit in the uses clause.

regards,

[DonAlfredo]

@wp:
Added print preview example (not 100%).
https://github.com/LongDirtyAnimAlf/mORMotPlanIt

@Dimitrios Chr. Ioannidis
To get 100% test success, you need trunk !
There are some fixes in trunk that are needed by the mORMot !!

[d.ioannidis]

Hi Alfred,

[snip]
@Dimitrios Chr. Ioannidis
To get 100% test success, you need trunk !
There are some fixes in trunk that are needed by the mORMot !!

maybe so, but I don't use trunk .

Trunk, for my purposes, is a running target. I prefer fixes branch.

regards,

[DonAlfredo]

The next fixes release is close (3.0.2).
I will look into it when this 3.0.2 is released !

[wp]

Added print preview example (not 100%).
https://github.com/LongDirtyAnimAlf/mORMotPlanIt

Thanks. In the meantime I found a rather detailed documentation of printing in the pdf which I referred to somewhere above - shame on me...

Looks like there's a lot to do here too: The printer does not start, the navigation and print icons are drawn terribly, the previewed page is always square, selecting another format from the preview does not change anything etc.

[DonAlfredo]

@Dimitrios Chr. Ioannidis

I have a version of the mORMot ready for the fixes branch of FPC.
Would you mind testing it ?

Thanks.

https://github.com/LongDirtyAnimAlf/mORMot