What about having a MongoDB FireDAC driver, and complex data types in a grid? http://community.embarcadero.com/write-blog-post/entry/coming-soon-to-rad-studio-firedac-nosql-driver-for-mongodb
What about having a MongoDB FireDAC driver, and complex data types in a grid? http://community.embarcadero.com/write-blog-post/entry/coming-soon-to-rad-studio-firedac-nosql-driver-for-mongodb
Heard this was coming back in April (on the hush hush) :-)
ReplyDeleteNice work!
We have that already: http://blog.synopse.info/post/2014/05/07/MongoDB-database-access, And the advantage is that you don't need the latest Delphi in order to use it!
ReplyDeleteCompetition is good. Pick the fastest one. https://github.com/stijnsanders/TMongoWire
ReplyDeleteIt also depends if you need to swap one DB for another - This is where Emb has an advantage with FireDAC.
ReplyDeleteBut yes, competition is good :)
Nicholas Ring That's not really the advantage of FireDAC, as of today, Synopse mORMot supports MongoDb, SQLite3, MSSQL, Oracal, DB2, PostgreSQL, MySQL, Firebird, MS Access, NexusDB, TObjectList in memory, and *any DB* supported by these DB access layer: FireDAC, UniDAC, ODBC, ZEOS, BDE and Jet: http://blog.synopse.info/post/2014/03/07/Support-of-MySQL%2C-DB2-and-PostgreSQL . So the truth is the opposite, I must say.
ReplyDeleteEdwin Yip All through the one interface? Nice! I didn't know that. Thanks for setting me on the straight and narrow :-)
ReplyDeleteYes, not only the DB access classes in the mORmot framework, but the ORM part also support all these DB's, and I think A. Bouchez can answer you better :)
ReplyDeleteNicholas Ring Edwin Yip FireDAC MongoDB would need to use a dedicated query construction for MongoDB, incompatible with SQL. So you can't switch from SQL to NoSQL directly, but rewrite all your requests for MongoDB. And it suffers from the "flat" RDBMS approach of the TDataSet: difficult to work with nested documents, from the RAD approach. I'm curious how they manage to do it. IMHO using MongoDB like a RDBMS is pointless.
ReplyDeleteOur ORM, on contrary, is able to convert the WHERE clause of its data retrieval from SQL like syntax to MongoDB. So you can switch from a SQL to a NoSQL backend in a single line of code. See e.g. https://github.com/synopse/mORMot/tree/master/SQLite3/Samples/30%20-%20MVC%20Server
And, on the other hand, we integrate also document-like storage in SQL databases.
See http://blog.synopse.info/post/2015/08/23/SQLandNoSQL No problem storing complex documents within MongoDB, and handle them in code.
About performance, mORMot interfaces directly its JSON structures to MongoDB BSON. We achieved amazing speed in production. As SQL backend of our ORM, FireDAC was slower than our direct classes. Maybe someone would do a benchmark.
But both approaches are fine, and in fact diverse. FireDAC is RAD-centric, whereas mORMot is clearly REST/nTier/SOA/ORM from the ground up. With FireDAC, you use your mouse and components, whereas with mORMot you write code in services, and split the logic from the UI (up to a Domain Driven Design architecture).
Marco Cantù BTW the blog page is unreachable now. At least from Europe.
ReplyDeleteA. Bouchez As you say at the end, mORMot and FireDAC have a different approach and focus on different problems. But it was on "your side" that the comparison was introduced.
ReplyDeleteHaving said this I hate this attitude of criticizing a solution before knowing it. The previous message has a lot of FUD about FireDAC MongoDB support. TDataSet is richer than you depict it, and in fact the image in the article even shows a DBGrid connected to a TDataSet with abstract data types and nested tables. Not saying it covers all scenarios, it does not, but your flat criticism is incorrect. And so are the comments about JSON and BSON processing, direct access to MongoDB features and more.
I have no issue when you explain the virtues of your solution (which has some great advantages but also limitations, as any solution), but criticizing what Embarcadero does before knowing the technical details with the attitude "just because it comes from them it cannot be good" is rather annoying.
Marco Cantù Blog page is back.
ReplyDeleteAFAIR I did not start the comparison, but Edwin Yip asked explicitly for more information.
AFAIK I wrote "FireDAC MongoDB would need to use a dedicated query construction for MongoDB, incompatible with SQL" is not FUD. It is a fact, shown even by the blog screenshots. You can not switch from one DB to another easily. It is a fact, from the architectural/design point of view: you need an ORM/ODM (or something similar) to abstract the storage layer.
I wrote I was "curious" about how NoSQL concepts were translated to RAD. I'm still not convinced that nested tables with fixed column names do match the "Aggregate SchemaLess" main benefit of NoSQL.This is RDBMS master/detail in disguise.
But I was not right when I wrote that MongoDB was "somewhat restrained to the TDataSet". Like any FireDAC units, you can have direct low-level access to the driver. Even if I wonder which percentage of users do talk directly to the FireDAC.Phys.*.pas units. So it was a "somewhat" practical "restriction".
I edited my post, too much quickly written. I feel sorry if it sounded like FUD. I was wrong in part of my comment. I corrected it. I even thank you for your feedback, even if you answered with "hate" attitude - impugning motives is never helpful. What do you fear?
I never wrote that anything new from Embarcdero "cannot be good". On the contrary, FireDAC is a nice part of Delphi. I wrote that its "approach was fine". We have support for it in mORMot, with no negative terms about it, on the contrary - see http://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITLE_178 - we even support some of its features (like array binding).
Like with the old Greek language style, the main point of my post was its final paragraph.