mORMot Open Source

Actually, I mean the stability status of the current version of the spidermonkey wrapper, is it alpha, beta or production-ready? Thanks.

Great! Thanks!

Looks like it just works! Any thoughts as to can we use it in production?

WOW! This is incredibly awesome!!!

With ES6 is being standardized, the JS language will be much more close to what Delphi/C# programmers would expect (think TypeScript).

I think this project can at some degree solve, 1) the shortage Delphi developers in the market, 2) the shortage of Delphi libraries nowadays. How? By delegating some of the implementations to JS developers!

I also think if this project done right and well, can add one of the major benefits of dynamic languages - interactive development (no compilation is needed)!  Imagine when your programs runs in DEBUG mode, you can call up an integrated JavaScript code editor with code-complete, edit and click save, and our program is enhanced!

If you still don't understand the benefit of interactive programming, maybe I can put it in another way - this can completely replace debugging tools such as CodeSite, and does much more. But interactive programming is so much more than that, go do a google yourself

PS, re auto-publishing of Delphi objects, I think you should provide a way (maybe by using Attributes) to specify which objects we do/don't want to expose to JS.

ps2, I have a live html/css code editor called LIVEditor that might need this SpiderMonkey wrapper, and I wish it can be used standalone - without other parts of the Synopse framework - which are gems but I don't need

Thank you guys!

Good news Arnaud!

Hi Arnaud,

Thank you very much. That helps.

the background: I'm designing a DB to store millions of objects of different structure, so to make things simplified, the DB will only have two types of objects, or in other words, two tables:

TMyDocument = class(TSQLRecord)
  PrimaryKey: Integer; //primary key of the object
  MetaDataAsJSON: RawUTF8; //object properties in JSON format.
end;

//store blob datas of TMyDocument, can have many instances that are associated with TMyDocument.
TMyBlob = class(TSQLRecord)
  PKey: Integer;//primary key
  FKey: Integer;//foreign key, maps to TMyDocument.PrimaryKey
  MetaDataAsJSON: blob;//blob data, I still don't know what data type to use here, but you should get my point.
end;

unbelievable! Very few open source projects are so well documented!

Thanks Arnaud, in the model layer I use a object model that uses properties such as Parent, PrevSibling, NextSibling, InsertChild, DeleteChild, etc, and these members are necessary when implement the program logic, just like a generic tree data structure.

But here we are taking about persisting the objects.  When saving to the database I use "ParentId" and "Idx" table fields instead, to simply things.

Thanks for the helpful info, Arnaud!

I'll be pleased to post some helpful code here if I even go for this approach, at this moment I'm just doing some technical research for a planned program.

If the Python code will talk to the server via http/json, I'm still wondering how the server side code will look like, which method should I use/extend?

Thanks!

Wow! The batch update mode is great!

Well done, Arnaud, you are fast.

Maybe the use of 'documents' misled you, actually, it'll be a program that need to store a wide variety of different types of objects.

Hi Arnaud,

While it'll be perfect if you can remove the limit (imagine large projects that will have over 64 types of objects that need to persist), I think I've come up with a workaround:

For saving:
1 - On the client side, encode the TSQLRecord-derived objects to JSON strings;
2 - Call the server side method to pass the JSON strings;
3 - On the server side, decode the JSON strings back to objects;
4 - Call the direct sqlite restful server to persist the object

And do the other way around when the clients need to retrieve objects from the server.

It's still quite neat IMHO, thanks to the excellent framework.

HI Arnaud,

Sorry for the late response. Yes, I agree that in most apps 64 tables would be enough, but in some cases, my case include,  64 tables is not enough. As you might remember in another post I'm planning to use Synopse sqlite to store various "documents", and the app will continue adding support for more type of documents, it will reach the 64-table limit at the end but 256 will be enough.

Or, if I don't use the permission-related features, can we remove this limit? Maybe via a conditional define?

Thanks!

Hi Arnaud,

This is a serious limit, SQLITE itself doesn't have such limits, right? Will remove this limit in the future?

And is there any other limits Synopse SQLITE introduced?

Thanks!

Thanks for the info, Arnaud!

I'm wondering if you think that it's a good idea that offering multiple versions of the sqlite3 objects, for example, one with this ICUenabled option defined...

Thanks for the link, ab.

Is Synopse SQLITE compiled with the SQLITE_ENABLE_ICU pre-processor symbol defined? Thanks.

Thanks for the sample code! But I don't understand, what's the advantage of using TSQLTableJSON?

One more question, for some reasons, I can't use tbigtable but want to store the logs to a SQLITE DB instead. I'll use TSQLRestClientURINamedPipe server component, and I'm wondering if I can have multiple TSQLRestClientURINamedPipe instances - one for the main data while another for logs only, so that I can save my logs to a separate database. But I read the following line in the source code:

// - allows only one ExportServer*() by running process

Does it mean it's not possible? And I found this  similar thread about TSQLite3HttpServer

Well, forget about this question, I read the following release notes in the source file:

    Version 1.7
    - alter table with newly added fields to a TSQLRecord (see GetSQLAddField()
      methods)

Great advise! I'll check TSynBigTable!

Hi ab,

Can you give me some hint or a few lines of sample code to get me started using TSQLRecordLog?

Can I store the logs to an external database, rather than the main database?

Thank you!