Pages: 1 … 4 5 6

#251 Re: mORMot 1 » Nullable types for mORMot » 2015-06-25 07:44:16

hnb

Another solution (IMO the best):

  TSQLexample = class(TSQLRecord)
  protected
    ftest: Variant;
    fstrtest: Variant;
  published
    property test: Variant index NULLABLE_INTEGER read ftest write ftest; // NULLABLE_INTEGER = -1, NULLABLE_DATETIME = -2 etc.
    property strtest: Variant index 30 read fstrtest write fstrtest; // similar to property strtest: RawUTF8 index 30 (...)
  end;

#252 Re: mORMot 1 » Nullable types for mORMot » 2015-06-25 06:48:21

hnb

IMO idea to use a "Nullable* = type variant" definition is more "Convention over configuration" smile. Especially for mixing "database-first"/"code-first" ORM coding, where I have a tons of Nullable* columns.

Sadly we can't use TNullable<Integer>... FPC don't allow this kind of type in published section...

Solution with single sftVariant kind of field needs more (much more...) configuration from code level, for example:

// nt* = Nullable Type Enum
fModel.Props[TSQLRecordWithVariants].ExternalDB.
  MapVariantFieldType('foo', ntInteger).
  MapVariantFieldType('YearOfDeath', ntDateTime);

Using few more types like sftVariant don't bring much more code.

The decision is yours.

#253 Re: mORMot 1 » Nullable types for mORMot » 2015-06-24 20:13:37

hnb

I do not know whether the technique is correct (just a concept). Patch is ofc not finished. I ask before I start further work on this.

#254 mORMot 1 » Nullable types for mORMot » 2015-06-24 11:27:24

hnb
Replies: 22

Hi,

Next episode for "NULL" story.

I really need use more precise ORM system for master/slave replication. For master is used "database-first" approach (PostgreSQL), but for slave client on android is used "code-first". The problem exist for "SlaveServer.CreateMissingTables". Slave table is very different from master table. All columns created for table from published variant property they are "TEXT", but I need them as TDateTime (TEXT COLLATE ISO8601) or as Integer, and I need to be able set theirs values to NULL from ORM.

My initial solution:

  TSQLexample = class(TSQLRecord)
  protected
    ftest: NullableInteger;
  published
    property test: NullableInteger read ftest write ftest;
  end;

"draft patch" with NullableInteger and NullableDateTime attached:

https://drive.google.com/file/d/0B4PZhd … sp=sharing

Patch can be extended for new nullable types and type checking in new classes like TSQLPropInfoRTTINullableInteger, TSQLPropInfoRTTINullableDateTime etc.

regards,
Maciej Izak

#255 mORMot 1 » Loosing NULL value for Variant » 2015-06-23 21:53:13

hnb
Replies: 1

NULL value for published Variant properties is stored correctly in DB but when data is received then NULL value is loosing (variant is unassigned).

Very painful especially for "database-first" approach (existing infrastructure, related to very big project, where I can't resign from the NULL).

Super simple test-case:

type
  TSQLtest = class(TSQLRecord)
  protected
    fv: Variant;
    fVersion: TRecordVersion;
  published
    property v: Variant read fv write fv;
    property Version: TRecordVersion read fVersion write fVersion;
  end;

function GetModel: TSQLModel;
begin
  Result := TSQLModel.Create([TSQLtest, TSQLRecordTableDeleted]);
end;

var
  MasterServer, SlaveServer: TSQLRestServerDB;
  Model: TSQLModel;
  t: TSQLtest;
begin
  Model := GetModel;

  MasterServer := TSQLRestServerDB.Create(Model, ':memory:');

  MasterServer.CreateMissingTables;

  t := TSQLtest.Create;
  t.v := NULL;
  WriteLn(VarTypeAsText(VarType(t.v)));

  MasterServer.Add(t, true);
  t.Free;

  t := TSQLtest.Create(MasterServer, 1);
  WriteLn(VarTypeAsText(VarType(t.v)));


  SlaveServer := TSQLRestServerDB.Create(Model,':memory:');
  SlaveServer.CreateMissingTables;
  SlaveServer.RecordVersionSynchronizeSlave(TSQLtest, MasterServer);

  t.free;
  t := TSQLtest.Create(SlaveServer, 1);
  WriteLn(VarTypeAsText(VarType(t.v)));

Output:

Null
Empty
Empty

anyway patch is attached:
https://drive.google.com/file/d/0B4PZhd … sp=sharing

other patch for "typo" bug:
https://drive.google.com/file/d/0B4PZhd … sp=sharing

output with first patch:

Null
Null
Null

best regards,
Maciej Izak

#256 mORMot 1 » nullnull in where section » 2015-06-23 08:26:09

hnb
Replies: 1

Hi,

when I am using "is null" in code like:

st := TSQLsometable.CreateAndFillPrepare(client, 'x is null');

then I have got error from server side

First chance exception at $7607C42D. Exception class EZSQLException with message
'SQL Error: ERROR:  syntax error at or near "nullnull"
LINE 1: ... from sometable where x is nullnull

anyway patch is attached:
https://drive.google.com/file/d/0B4PZhd … sp=sharing

how can I add patch/attach file by http://synopse.info/fossil/ ?
or maybe can I send pull requests by https://github.com/synopse/mORMot ?

best regards,
Maciej Izak

#257 Re: mORMot 1 » Android TSQLHttpClientWinSock connect problem » 2015-06-19 20:10:39

hnb

Now works perfect. Even SendTimeout and ReceiveTimeout in TSQLHttpClientWinSock.InternalCheckOpen is now covered.

Thanks.

#258 Re: mORMot 1 » Android TSQLHttpClientWinSock connect problem » 2015-06-19 12:38:21

hnb

Why you have added ConnectTimeout optional parameter only for TSQLHttpClientRequest? I need ConnectTimeout for TSQLHttpClientWebsockets/TSQLHttpClientWinSock smile.

#259 mORMot 1 » Android TSQLHttpClientWinSock connect problem » 2015-06-19 11:04:50

hnb
Replies: 8

Hi,

I am using mORMot for Android client (FPC 3.1.1 r30739). I have problem when server is unavailable (for TSQLHttpClientWebsockets/TSQLHttpClientWinSock).

  aClient := TSQLHttpClientWebsockets.Create(cfg.IP, cfg.Port, aModel);
  aPerson := TSQLperson.Create(aClient, someID); // this line is freezing application for more than 60 sec

In windows client all works fine (the client application does not stop on the line mentioned above). Anyway i found solution (maybe not perfect but now is possible to set timeout in overloaded constructor in TSQLHttpClientWinSock). Patch attached:

https://drive.google.com/file/d/0B4PZhd … sp=sharing

best reagrds,
Maciej Izak

#260 Re: mORMot 1 » More human readable way for TDocVariant » 2015-06-16 08:34:54

hnb

Thanks. Works like a charm.

#261 mORMot 1 » More human readable way for TDocVariant » 2015-06-15 10:21:08

hnb
Replies: 2

Hi :)

mORMot is amazing, thanks for great work.

I have small problem. How can I save TDocVariant in a more human readable way?

I need this for settings. For example:

var
  cfg: Variant;
begin
  TDocVariant.New(cfg);

  cfg.Host := eHost.Text;
  cfg.Port := ePort.Text;
  cfg.DBName := eDBName.Text;
  cfg.User := eUser.Text;
  cfg.Passwd := ePasswd.Text;

  FileFromString(string(cfg), 'settings.json');
end;

best regards,
Maciej Izak

Pages: 1 … 4 5 6

Board footer

Powered by FluxBB