You are not logged in.
Pages: 1
SQLite3\sqlite3.obj is outdated.
Here are some samples from git history to visualize the problem:
fix is missing
error c7a6bcf3e ("updated SQLite3 Database engine to its latest 3.36.0 revision", 2021-08-24)
fix 8d95a1e1d ("update Delphi SQLite3 static files", 2021-05-04)
error a7be4539b ("updated SQLite3 database engine to latest 3.35.5 revision", 2021-04-23)
ok a9536b04e ("upgraded SQLite3 static version to latest 3.35.4", 2021-04-03)
fix 45dfffcf5 ("updated SQlite3 to the latest 3.35.3 revision", 2021-03-28)
error 81d6ddb50 ("updated SQlite3 to the latest 3.35.3 revision", 2021-03-27)
fix 50a477ee2 ("update outdated sqlite3.o/.obj static files", 2021-02-03)
error d6ab2f108 ("upgrade SQlite3 to latest 3.34.1 revision", 2021-01-25)
ok fac825474 ("upgraded the statically linked SQLite3 engine to latest 3.34.0 revision", 2020-12-03)
fix da993124e ("update SQLite3 static files for Delphi - fix for https://github.com/synopse/mORMot/issues/351", 2020-09-05)
error 90e62bfcb ("update SQLite3 static engine to latest 3.33.0 revision", 2020-09-02)
Would it be possible to better support Delphi Win32 users who are still using version 1? The last update of the sqlite3 files crashed our CI system again because the sqlite3.obj file in the repository is out of order. Thanks in advance
In our interfaces we are using types kind of "set of TMyEnumeration". Is it possible allow enumerations with more than 32 members in it?
Unfortunatly in such cases an exception is thrown at TInterfaceFactory.Create method.
EInterfaceFactoryException: TInterfaceFactoryRTTI.Create: TMyImplementation set invalid SizeInStorage=0 in IMyInterface.MyMethod method AMyEnum parameter
Some workouround would help:
function TEnumType.SizeInStorageAsSet: Integer;
begin
case MaxValue of
0..7: result := 1;
8..15: result := 2;
16..31: result := 4;
32..63: result := 8; // <--- added
else result := 0;
end;
end;
Is there a reason for limiting? We are using Delphi 10.3 Update 1.
Thanks in advance.
version 1.18.5053 breaks compilation if USE_WINIOCP is not defined.
this would fix the issue:
index 85e41cec..2b2e3c10 100644
@@ -1018,3 +1018,5 @@ type
fBodyOwnThreads: integer;
+ {$ifndef USE_WINIOCP}
function QueueLength: integer; override;
+ {$endif}
// here aContext is a pointer(TSocket=THandle) value
@@ -7127,2 +7129,3 @@ end;
+{$ifndef USE_WINIOCP}
function TSynThreadPoolTHttpServer.QueueLength: integer;
@@ -7133,2 +7136,3 @@ begin
end;
+{$endif}
was introduced with commit 1.18.4998
Embarcadero Delphi for Win32 compiler version 33.0
Copyright (c) 1983,2017 Embarcadero Technologies, Inc.
SynCommons.pas(56705) Warnung: W1073 Kombination von vorzeichenbehaftetem Typ und vorzeichenlosem 64-Bit-Typ - wird als vorzeichenloser Typ behandelt
with commits from yesterday some compile hints were introduced
Embarcadero Delphi für Win32 Compiler-Version 28.0
Copyright (c) 1983,2014 Embarcadero Technologies, Inc.
SynCommons.pas(26268) Hinweis: H2164 Variable 'PSAPI' wurde deklariert, aber in 'RetrieveSystemInfo' nicht verwendet
SynCommons.pas(56909) Hinweis: H2135 FOR oder WHILE Schleife wird nicht durchlaufen - gelöscht
SynCommons.pas(56907) Hinweis: H2164 Variable 'mem' wurde deklariert, aber in 'RetrieveInfo' nicht verwendet
SynCommons.pas(64489) Hinweis: H2164 Variable 'h' wurde deklariert, aber in 'TSystemUse.Create' nicht verwendet
consider using NoTimeStampCoherencyCheck, see https://synopse.info/forum/viewtopic.php?id=1983
In Javascript a stringified date looks like
JSON.stringify(new Date(1490875855648))
"2017-03-30T12:10:55.648Z"
Unfortunately this is not the same with mORMot:
UnixMSTimeToString(1490875855648, True, 'T', 'Z');
'2017-03-30T:12:10:55.648Z'
I suggest to change the value of SynCommons.DTMS_FMT[True] to
'%-%-%%%:%:%.%%'
So it would be conform with ISO 8601, as also mentioned in the comment 'YYYY-MM-DD hh:mm:ss.sssZ'.
Thanks.
@ab, thank you for the quick fix und thank you for this excellent piece of software
@ab, there is a BREAKING CHANGE introduced with this last commit https://synopse.info/fossil/info/e30de8cb21
TSQLModel.Root=""AAV/V1"" contains URI unfriendly chars".
A versioning of our services with an URI-Fragment is not possible any more.
@erick, you should redesign your landing page http://www.erickengelke.com/.
It's IMHO no good idea to present an EWB-Demo which scales horrific at mobile with GPRS (50kb/s download, 500ms latency), try ist with Chrome. 1.4 minutes to see a very small informational page? Is it worth to load a huge Framework here?
And: On a Smartphone there is no chance to buy your book. The Link is out of screen .
you are not alone, see Ticket http://synopse.info/fossil/info/d7dd444 … 21388bbd54
ab has written a sample doing this, have a look at "Samples/12 - SynDB Explorer" --> Button Query Builder --> Button To Object --> To One TSQLRecord per table. This should help as an entry point.
sorry, my mistake: The column type is TEXT as before. My DCU-file was not correctly updated
Thank you for the patch! It works like a charm
It should be noted that in SQLite the variant Details becomes a BLOB column (before the patch it was a TEXT column).
TDDDRepositoryRestFactory.ComputeSQLRecord is a very handy function. It does the mapping from pure DDD-Objects to ORM-Objects.
But with T*ObjArray seems to be problem. For example:
TDetails = class(TPersistent)
private
fName: RawUTF8;
published
property Name: RawUTF8 read fName write fName;
end;
TDetailsObjArray = array of TDetails;
TMaster = class(TSynAutoCreateFields)
private
fName: RawUTF8;
fDetails: TDetailsObjArray;
published
property Name: RawUTF8 read fName write fName;
property Details: TDetailsObjArray read fDetails write fDetails;
end;
initialization
TJSONSerializer.RegisterObjArrayForJSON(TypeInfo(TDetailsObjArray), TDetails);
The generated ORM-Object would look like
type
/// ORM class corresponding to TMaster DDD aggregate
TSQLRecordMaster = class(TSQLRecord)
protected
fName: RawUTF8; // RawUTF8
fDetails: variant; // TDetailsObjArray
published
/// maps TMaster.Name
property Name: RawUTF8 read fName write fName;
/// maps TMaster.Details
property Details: variant read fDetails write fDetails;
end;
The Details variant type becomes a TEXT column in SQLite: CREATE TABLE Master(..., Details TEXT COLLATE NOCASE);
But when creating a TDDDRepositoryRestFactory class there is an exception raised:
TDDDRepositoryRestFactory types do not match at DB level: TMaster.Details:TDetailsObjArray=42746606 and TSQLRecordMaster.Details:Variant=55746606
Right: aggregate SQLDBFieldType (sftBlobDynArray) isn't equal to record SQLDBFieldType (sftVariant).
By manual patching the generated TSQLRecord class to this, all the stuff is working fine:
type
/// ORM class corresponding to TMaster DDD aggregate
TSQLRecordMaster = class(TSQLRecord)
protected
fName: RawUTF8; // RawUTF8
fDetails: TDetailsObjArray; // TDetailsObjArray
published
/// maps TMaster.Name
property Name: RawUTF8 read fName write fName;
/// maps TMaster.Details
property Details: TDetailsObjArray read fDetails write fDetails;
end;
The corresponding TDetailsObjArray type becomes a BLOB column in SQLite: CREATE TABLE Master(..., Details BLOB);
Is it possible to compute T*ObjArray-Properties to appropriate types, or is there another solution?
Hi Arnaud, thank you for adoption and quick implementation. Works very well as expected.
BTW, one note to consider: shorthand overloaded function
AuthenticationRegister(const aMethods: array of TSQLRestServerAuthenticationClass)
falls into disuse for this new feature. But this has no impact, mORMot rocks Thank you very much!
Signed sessions are per design sequential. Every new signed session signature can't be older in time than the last one, see
function TSQLRestServerAuthenticationSignedURI.RetrieveSession
…
(aTimeStamp>=result.fLastTimeStamp) and // check time stamp coherency
Unfortunately this is an issue for us and prevents us from doing simple async AJAX-calls within one main session. We are using libraries like jQuery and source based on RangerX's auth-schema. In fact, it isn't possible to predict which in sequence signed AJAX-call will arrive at mORMot server at first. Especially with large BLOB-Uploads there are sometimes issues with 403-Forbidden ):
Surely, the problem can be solved with additional sessions for parallel tasks, but for our purposes it's good enough to comment out the aTimeStamp-Line, so that there is no more need of session-handling-overhead.
@ab, is there a way to allow this "weaker security" by the framework within a property or is there something that we have overlooked?
Pages: 1