You are not logged in.
Pages: 1
I never used SynDB before, so I don't knew how to rename a column in a SQLite3 table using mORMot.
Maybe this can be useful for someone.
var
Props: TSQLDBSQLite3ConnectionProperties;
begin
Props := TSQLDBSQLite3ConnectionProperties.Create('my-db.sqlite','','','');
Props.ExecuteNoResult('alter table my_table rename column OLD_NAME to NEW_NAME',[]);
end;
Offline
This is great!
Have you any trick regarding remove a column from an SQLite table?
Offline
It's not possible to remove column from SQLite table directly. The only way is to create new table w/o column -> move data from old table into new one (insert into .. select from ..) -> drop old table -> rename new table. This is by SQLite3 design.
Last edited by mpv (2020-06-02 18:35:27)
Offline
Yeah removing column I think that is not possible.
Offline
... time to compile the latest SQLite3, indeed!
And alter the ORM to support ALTER TABLE DROP COLUMN.
(even if not dropping a column won't break code not existing it of course - it will just reduce the disk space usage)
Offline
ab,
there is a relevant bug fix in 3.35.1
Offline
I was right waiting before the 3.35.0 release, then.
I am currently adding two new features to mORMot 2:
1/ https://github.com/ebiggers/libdeflate
2/ https://bellard.org/quickjs/
Those two need additional static files to be added, so I will wait until I stabilize them enough. Then release the new statics, including SQLite 3.35.1 (or 2,3...).
Offline
@ab, why a quickjs, it do not have JIT
Why not a ChakraCore https://github.com/chakra-core/ChakraCore
ChakraCore C API is perfect, speed is very good. Supported by MS.
Last edited by mpv (2021-03-16 17:45:17)
Offline
Just look again into ChakraCore, and YES, they adds a debugging API, https://github.com/chakra-core/ChakraCo … kraDebug.h, so remote debug protocol can be easy implemented, as we did in synode. This is the main feature what stops me from migrating to CK from SpiderMonkey. So I definitiatly try it.
Offline
SyNode looks excellent.
But I'm trying to add script support to an application, and I confess that I'm a little lost with versions.
I'll even try to add the LUA, as I don't need compatibility with Node.js and other more sophisticated features.
QuickJS and or ChakraCore, will be good additions.
Offline
The most natural solution would be some sort of pascal scripting written in pascal. The problem is that there does not seem to be any really good fit for mORMot.
Remobjects's Pascal Script is the only free one I know of which is mature enough and can be used with both Lazarus and Delphi. Unfortunately it does not allow script defined classes, which is important for ORM. Functionally something like PaxCompiler would be a good solution but it does not seem to be available even for purchase any more.
Freepascal JS compiler combined with the new JS engine might be a viable route for those who want to stick with Pascal even for scripting, but I do not see how debugging could work in this case.
Last edited by Leslie7 (2021-03-16 19:37:43)
Offline
Leslie7 - it's depends. JS is a good choice for at last 3 reason:
1) JS is popular - in my company 60 developers know JS and 2 pascal (10 years ago 60 pascal and 2 JS)
2) there is 100500 ready to use JS libraries, much more when for pascal
3) modern JS engines what supports JIT is VERY fast. For business logic cases as fast as a compiled code
Offline
ChakaCore was not an option, because it compares to V8/Spidermonkey, not QuickJS.
ChakraCore is abadonned by Microsoft now, IIRC.
And we have SyNode/SpiderMonkey, so no need of this JIT engine.
QuickJS is 700KB only, including BigInt/BigFloat (there is a RSA code in a single unit!), RegExp and full Unicode support.
With EcmaScript 2020 dialect, and written by one giant of the C libraries.
The alternative to QuickJS is DukTape, which is much slower, and Ecma 5 only.
Besen has a JIT and is pure pascal, but is less used, therefore less tested/proven.
QuickJS can store and run the byte code directly, so you even don't need to send the JS code.
And QuickJS has the latest Ecma Script standard, so you could feed it with http://www.transcrypt.org/ and run something coming from python code!
It has also excellent support of TypeScript input... and possibly pas2js if needed.
Check also https://github.com/Coldzer0/QuickJS-Pas … -523424692
(I used this wrapper as reference)
I Found a QuickJS fork very interrresting: https://github.com/c-smile/quickjspp - the guy added features and use it in its widely deployed JS/HTTP5/CSS stand-alone client library - https://sciter.com/
My goal is to have a statically linked JS engine to embed into applications, e.g. on client side.
I will make some abstract scripting abilitites to mORMot 2, to switch from QuickJS to your SpiderMonkey on need, e.g. on server side, where performance matters.
I would like to use interfaces and classes to define the module published to the JS code.
Note that QuickJS can run its JS code with very little delay, and is fast enough to execute any kind of workflow. So if you don't compute a mandelbrot it is fine. Even with its BigInt/BigFloat native support, and operator overloading, it is faster than Delphi or V8/SM for working with big numbers, if you have to deal with the numbers calculation in pascal or JS.
Now back to the coding. My preliminary phase of C compilation and static linking (with minor patch to force using the FPC heap) is very promising.
It will support FPC for static linking on at least Windows, Linux i386+x8664+Arm+Aarch64, and possibly external DLL for Delphi/Windows.
Offline
Offline
... did not see your last post.
Last edited by Leslie7 (2021-03-16 23:08:45)
Offline
BTW BigInt is implemented in all modern JS engine https://developer.mozilla.org/en-US/doc … cts/BigInt
Offline
Yes, BigInt is there, but QuickJS has BigDecimal, BigFloat support too!
The main advantage of QuickJS is its low memory usage.
A runtime, compilation and execution cycle consumes less than 60KB of memory. Try to beat that with JIT monsters!
Bellard is a C genius.
He wrote QEmu and FFMpeg...
And its C code in QuickJS is as much clear than it was obfuscated in Qemu. Brilliant mind for sure.
Offline
Leslie7 - it's depends. JS is a good choice for at last 3 reason:
1) JS is popular - in my company 60 developers know JS and 2 pascal (10 years ago 60 pascal and 2 JS)
2) there is 100500 ready to use JS libraries, much more when for pascal
3) modern JS engines what supports JIT is VERY fast. For business logic cases as fast as a compiled code
JS is widely known and used of course and you are right about all these. But there are good reasons why we still work with Delphi/Lazarus beyond maintaining legacy code as well.
And if the required skills are already there it would make sense to do the scripting in pascal too. It is much more productive and leaves less room for errors.
Being able to debug and fix errors in libraries can be very handy when you are short on time. I find it much more difficult to do this with JS.
I find development and testing - especially for mobiles - much faster if fixes, changes are introduced through scripting. When they are proven to be logically correct then I can compile the same pascal code to machine code into the application and deploy it when it is prudent.
Last edited by Leslie7 (2021-03-16 21:24:44)
Offline
@ab,
I'm so exciting about the upcoming integration of QuickJs to the mORMot framework!
Will it also available for mORMot 1?
BTW, I prefer js over pascal for **scripting*, because all the Pascal script engine are **dialects** (not fully compatible with Delphi or FPC). The main issue is that, when you have a problem, you'll find that you can't find enough documents, examples or other resources to help you solve the issue. On the other hand, you can instantly find a solution for any js problem!
Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.
Offline
Another bug fix on SQLite3: 3.35.2
https://www.sqlite.org/releaselog/3_35_2.html
And there are issues pending in the SQLite3 forum, e.g. https://sqlite.org/forum/forumpost/737cf80ece
We will wait a little until stabilized.
About QuickJS, I will put it into mORMot 2, but anyone could backport it to mORMot 1 and make a pull request.
Offline
edwinsn,
dialects usually introduce some additions which can be ignored for compatibility. Lack of documentation/support can be a problem for free solutions. This is why PaxCompiler was worth it's money. Because of the lack of proper free solutions I think probably there is still place for a similar commercial product.
Last edited by Leslie7 (2021-03-18 09:52:12)
Offline
ab,
do you already have a concept on how JS debugging could work? I started to think if it was a viable option to bridge the JS debug info with Lazarus + pas2js. With such an addition it would practically make pascal scripting possible too.
https://github.com/koush/vscode-quickjs-debug
Last edited by Leslie7 (2021-03-18 12:14:36)
Offline
About QuickJS, I will put it into mORMot 2, but anyone could backport it to mORMot 1 and make a pull request.
Sounds cool! Maybe one can use mORMot v1 and v2 together...
Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.
Offline
@ab,
A side question - what's your tool chain for fiddling the c/c++ stuff like this?
Delphi XE4 Pro on Windows 7 64bit.
Lazarus trunk built with fpcupdelux on Windows with cross-compile for Linux 64bit.
Offline
I just saw that the quikjs is already in the mORMot2.
I'll try.
Thanks
Offline
@ab, I propose to create a top level forum topic (on the same level as synode) for quickjs. It allows to group a quickjs related discussions..
After reading a lot about quickjs and looking through its sources I think it's very promising, especially after mozilla stops support SpiderMonkey as a separete project. Even docs is now not accessible
Last edited by mpv (2021-03-22 22:13:51)
Offline
Good idea.
I have created https://synopse.info/forum/viewforum.php?id=23
Offline
Pages: 1