Edit/Update: Issue fixed!
Allen Bauer recognized that "It was an uninitialized memory allocation" in the QC, and that he is pushing to include the fix into the upcoming Seattle 10 Update 1.
Nice seeing such a quick reaction. Delphi is not dead, even if Embarcadero was just acquired!
Please have a look at
http://lists.freepascal.org/pipermail/f … 35891.htmlLooking forward to your work !
Thanks, I observe this subject. New FreeSparta version will take some time.
]]>Please have a look at
http://lists.freepascal.org/pipermail/f … 35891.html
The branch is not yet fully working (some files are missing).
Some RTTI return values have also changed, but luckily do not influence the RTTI part of mORMot !
Looking forward to your work !
]]>Such FreeSparta with mORMot would be just great!
I have plans to release full free edition of FreeSparta with mORMot ^^ and with patched compiler (eg. by -> http://svn.freepascal.org/cgi-bin/viewv … rfacertti/ to perform Linux servers out of box).
]]>I'm committed to mORMot, sometimes over-enthusiastic.
But without passion, this Open Source project would not be what it is.
Our framework is an opportunity to Delphi or Embarcadero, not a competitor.
IMHO most mORMot users do still use Delphi because of mORMot, otherwise they would have switched to Java or C#.
We like Delphi, as a language and a platform. We leverage decades of (object) pascal practice.
Certainly Marco did "hate" those posts:
http://blog.synopse.info/post/2012/08/2 … -PRO-users
http://blog.synopse.info/post/2013/05/1 … sapointing
http://blog.synopse.info/post/2015/05/0 … ot,-do-you
http://blog.synopse.info/post/2015/06/2 … han-Delphi
IMHO those posts should not be "hated".
They should be taken for what they are: opinions and feedbacks of a long time Delphi user.
Hearing from customers is part of the business, right?
I sometimes react, because I like Delphi, and want it to be always better.
And I know I'm not the only one.
On Google+ - see https://plus.google.com/+MarcoCantu/posts/d7TJDTSZV4Q - I answered to a Edwin Yip question about mORMot MongoDB abilities.
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.
Our 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/ … C%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).
One of my points was wrong.
But Marco over-reacted:
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.
Having 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.
I'm honnestly feeling it pretty unfair.
Here is my answer:
Blog page is back.
AFAIR I did not start the comparison, but 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% … #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.
I emphasized in bold/strong my thought.
All this is pretty unfair.
A few weeks ago (end of june), I got a mail from Marco.
Sorry for the delay. We can accept this SynPdf submission and the SynGDIPlus
submission as well, although I’m personally a bit worried about a
partnership with someone who tends to take excuses to be negative with our
product, like your recent post about compiler optimization based on one
single codegen scenario.Regarding the SynCrypto, this is a great library, but we have legal
concerns, as in general as a US company hosting encryption code can be
done only following very specific rules and/or asking for government
authorization. We do it for the limited code we ship, but it becomes
tricky for an external submission.Regarding mORMot, it is currently on hold as it is not in line with GetIt
policies. We’ve asked internally to double check this, but we really don’t
want to have customers using GetIt adding to Delphi Professional
capabilities that are in the “Enterprise” space. I know what you have
written about this, but this has always been the case in the product since
day one. Even if our license can be bypassed in a "formally legal" way, it
does mean we are happy about it and will incentivate it. Delphi Pro is a
product for those who don’t need client/server database connectivity.
So you got the info.
This answer does make sense, from the Embarcadero point of view.
I do not want to argue about it.
In fact, my blog article was realistic.
I did not want to be negative, nor cynic.
But in France we use to say "Chat échaudé craint l'eau froide" - "once burned, twice shy"...
And... I was pretty right when I wrote that "the main ORM/SOA/REST/MVC/StubMock features would certainly be rejected".
Eventually, it has been the case.
No surprise.
Therefore no offense.
8)
BTW, SynPdf is not part of GetIt yet. Even if it is a very known and widely used library (probably the best Open Source PDF library for Delphi).
Perhaps, since SynCrypto is used within SynPdf (for PDF encryption - which is a nice feature), they were not able to add it.
So it was even worse than I expected.
But the few current GetIt components are great, especially OmniThreadLibrary and ICS.
The Delphinus PackageManager is a tempting alternative.
See http://blog.synopse.info/post/2015/08/2 … ageManager
Still in preview state, but some nice ideas, like the fact that it retrieve its information directly from GitHub search API.
But I still do not agree with their position, in respect to other packages managers, in c#, perl, python or ruby.
They have a very close spirit.
As with my negative reaction: "once bitten, twice shy"...
]]>As to the "spirit of licensing and editions" I think it is fairly obvious what they are referring to. They don't want to put anything on GetIt that would cost them any significant amount of sales. It has nothing to do with your or mine Delphi end-user license terms as far as I can see.
]]>My first version of Delphi was version 3 which I got on the cover of a UK computer mag. I just paid £20 for the printed docs. Then bought Delphi 5 as a shrink wrapped box off eBay and upgraded it a couple of times. If I'd had to pay the full price I wouldn't have used it.
]]>Is it true that "strong client/server RDBMS integration require an Enterprise edition" ?
We will bias acceptance toward GetIt libraries that respect the spirit of our licensing and editions, not just use the letter of the license and the technical boundaries. If you are unsure about your submission please check with us first.
http://community.embarcadero.com/index. … s-to-getit
What the fox is this "spirit of our licensing and editions"?
Why is it not part of the official license terms?
Where does this assumption comes from?
Would the licensing conditions change in the close future, as with the XE3 "episode"?
Would the Marco interpretation become the new rule?
Story repeats itself.
I just wanted to ensure that the licensing terms would not change in that direction.
I - as many Delphi users - would not let this GetIt "spirit" become the new rule.