Batch.PrepareForSending result and future usage

hnb · 2015-09-24 09:19:26

Hi,

I am using Batch.PrepareForSending for tracking changes on client side. In some point all is transferred to the server (access for many clients to single table and sync). Can we create some public method like protected TSQLRest.EngineBatchSend to handle Data received from PrepareForSending?

ab · 2015-09-24 11:28:05

On which side?

hnb · 2015-09-24 11:52:17

ab wrote:

On which side?

Damn, NVM, I have direct access to protected EngineBatchSend from server side. So this is solved But I have another issue witch batching:

When I pass object for Add/Update and this object is the child class (different class than declared in batch constructor), I need to create additional class and useless assign operation:

      b := TSQLRestBatch.Create(aRestServer, TSomeRec);
      // CACHE_someRec is array of TCACHE_SomeRec (where TCACHE_SomeRec = class(TSomeRec); ) 
      r := TSomeRec.Create;
      for i := 0 to High(LCache.CACHE_someRec) do
      begin
        r.FillFrom(LCache.CACHE_someRec[i]);
        b.Add(r, true);
      end;

instead of:

      b := TSQLRestBatch.Create(aRestServer, TSomeRec);
      for i := 0 to High(LCache.CACHE_someRec) do
        b.Add(LCache.CACHE_someRec[i], true);

Is any reason for blocking second example?

Last edited by hnb (2015-09-24 11:58:09)

ab · 2015-09-24 12:32:38

In Delphi, TCACHE_SomeRec = class(TSomeRec) in fact defines ANOTHER class.
The instance ClassType property won't be the same.
In the database model, it would create ANOTHER model.

So TCACHE_SomeRec is not a TSomeRec, so it is refused by TSQLRestBatch.Add().

If you just need code-level class difference, and not ORM/DB differnce, why not just define TCACHE_SomeRec = TSomeRec ?

hnb · 2015-09-24 12:49:03

ab wrote:

In Delphi, TCACHE_SomeRec = class(TSomeRec) in fact defines ANOTHER class.
The instance ClassType property won't be the same.
In the database model, it would create ANOTHER model.
So TCACHE_SomeRec is not a TSomeRec, so it is refused by TSQLRestBatch.Add().
If you just need code-level class difference, and not ORM/DB differnce, why not just define TCACHE_SomeRec = TSomeRec ?

At client/slave side I need to hold two tables: CACHE_SomeRec (new records for SomeRec) and SomeRec (for data received from server/master). I have full working implementation of read/write for many slaves.

I don't want the same ClassType, all of above is intended IMO TSQLRestBatch.Add() should accept child class like FillFrom method.

Last edited by hnb (2015-09-24 12:58:47)

ab · 2015-09-24 12:57:07

The ORM follows the class mechanism.
Each type = one table.
So when you want to add something to TSomeRec, you need to use a TSomeRec instance, not a TCACHE_SomeRec.

hnb · 2015-09-24 13:12:40

ab wrote:

The ORM follows the class mechanism.
Each type = one table.
So when you want to add something to TSomeRec, you need to use a TSomeRec instance, not a TCACHE_SomeRec.

So I will use FillFrom as above to omit this design .

mORMot works great on Android with FPC! Would be terrible get stuck with NEXTGEN Delphi compiler.

ab · 2015-09-24 13:19:20

FillFrom() would have a very small overhead.
Every value would be copied by reference, so no memory would be allocated.

Or you may hack the instance type as such:

for i := 0 to High(LCache.CACHE_someRec) do
      begin
        PPointer(LCache.CACHE_someRec[i])^ := TSomeRec;
        b.Add(LCache.CACHE_someRec[i], true);
        PPointer(LCache.CACHE_someRec[i])^ := TCACHE_SomeRec;
      end;

But it is a weird hack...

hnb · 2015-09-24 13:34:52

Great!

So I will use less weird hack: PSQLRecordClass instead of PPointer

Thanks!

hnb · 2015-09-25 07:35:45

Maybe can we add new overloaded Add for TSQLRestBatch?

function TSQLRestBatch.Add(Value: TSQLRecord; SendData: boolean; ForceRecordClass: TSQLRecordClass; ForceID: boolean=false;
   const CustomFields: TSQLFieldBits=[]; DoNotAutoComputeFields: boolean=false): integer;
var
  DefaultClass: TSQLRecordClass;
begin
  result := -1;
  if (self=nil) or (Value=nil) or (fBatch=nil) then
    exit;

  if not PSQLRecordClass(Value)^.InheritsFrom(ForceRecordClass) then
    exit;
  
  DefaultClass := PSQLRecordClass(Value)^;
  PSQLRecordClass(Value)^ := ForceRecordClass;
  result := Add(Value, SendData, ForceID, CustomFields, DoNotAutoComputeFields);
  PSQLRecordClass(Value)^ := DefaultClass;
end;

Last edited by hnb (2015-09-25 09:55:43)

ab · 2015-09-25 09:58:36

Sounds pretty specific, and like a workaround of the ORM and whole Delphi class design.

You could write your own function or class helper to add this, but I doubt adding it to TSQLRestBatch would bring anything but confusion...

hnb · 2015-09-25 10:25:57

Probably this will be part of bigger patch for master/slave replication.

mORMot Open Source

#1 2015-09-24 09:19:26

Batch.PrepareForSending result and future usage

#2 2015-09-24 11:28:05

Re: Batch.PrepareForSending result and future usage

#3 2015-09-24 11:52:17

Re: Batch.PrepareForSending result and future usage

#4 2015-09-24 12:32:38

Re: Batch.PrepareForSending result and future usage

#5 2015-09-24 12:49:03

Re: Batch.PrepareForSending result and future usage

#6 2015-09-24 12:57:07

Re: Batch.PrepareForSending result and future usage

#7 2015-09-24 13:12:40

Re: Batch.PrepareForSending result and future usage

#8 2015-09-24 13:19:20

Re: Batch.PrepareForSending result and future usage

#9 2015-09-24 13:34:52

Re: Batch.PrepareForSending result and future usage

#10 2015-09-25 07:35:45

Re: Batch.PrepareForSending result and future usage

#11 2015-09-25 09:58:36

Re: Batch.PrepareForSending result and future usage

#12 2015-09-25 10:25:57

Re: Batch.PrepareForSending result and future usage

Board footer