YesSql 3 is here! Check out our current post to see what's new in YesSql, but first, read the new Liquid Widget guide and get to know why do the community needed to delete the Liquid Page and the Liquid Widget from the Blog and Agency recipes!
Orchard Core updates
Remove liquid type from recipes
Liquid widget guide
As we mentioned previously, the Liquid Widgets from the default recipes were just removed. But that content type served as a very good example of how you can work with Liquid in Orchard Core. To have an example for working with Liquid, you will now find a new guide in the documentation about how to build a new Liquid Widget. Sometimes not having a feature but documenting how to use something is better than having a feature and no documentation about it.
Did you know that our Helpful Extensions module for Orchard Core contains a Liquid Widget too, that adds Liquid code editing and rendering capabilities? Check out that repository for more goodies like the content definition code generation or the flows helpful extensions and many more!
Use nameof for action name whenever it's possible
Any controller action name that doesn't change can be called by using the
nameof expression of C#. Now you won't break anything if you change the name of a method during some refactoring.
Contents GetAsync: Recall published items
IContentManager.GetAsync(string contentItemId, VersionOptions options) use
IContentManagerSession.RecallPublishedItemId() to retrieve an already loaded content item if the request is to get a published item. The same could be used in
GetAsync(IEnumerable<string> contentItemIds, bool latest = false) (i.e., the overload accepting multiple IDs).
And the fix is here! When you do some loads with the content manager and if the content items are already have been loaded previously in the same request, there is no query that needs to be issued or just for the items that are missing.
In the previous version of YesSql, every session created a new transaction automatically by default. Every session means even if your session is only doing reads. But when you are doing reads, you don't need a transaction because every read will be using the same transaction resolution. When you start a session in YesSql 3 and it's just about doing reads (like SELECTs) then it won't create a transaction. But the first time when you do a change on an object, the transaction will be created automatically (like when you would like to update a content item). Now it lazily creates a transaction if there are UPDATE, DELETE or INSERT statements.
The second change is that if you really want to decide when the transaction should be created and not to wait for it to be automatically created. You can now call
BeginTransaction and that will create a transaction or return the existing one if one is still open. And then there is another property (
CurrentTransaction) that gives you either the existing transaction or NULL if there is no transaction.
Everything has been renamed from
SaveChangesAsync. It's like in Entity Framework and now it's more obvious to know what it does (saves the changes). And what it means is that at that point if there is a transaction it will be committed and then released. If there is no transaction, it's just do nothing.
And there is still the AutoFlush, meaning if you do some updates and then do a query to get some data, it will flush the changes from the database without committing a transaction, but your next request will be able to read the values that aren't in the database.
Something that you can't do with YesSql before is let's say you start creating a session and there is an exception in the middle. If you didn't do a try-catch, and call CANCEL on the catch, it would commit the transaction because disposing of the session was committing the changes. In ASP.NET we don't have this issue because there is a rule that catches any exception that happens anywhere in the pipeline. But in some other apps, if you forget a try-catch, it would commit the changes even if it didn't go over the full list of commands that you want to execute. That was a big issue in YesSql. So, now that's actually changed. Meaning that if you don't call
SaveChangesAsync now, it won't save anything. You have to call
SaveChangesAsync at some point to commit the transaction. And if you disposing the session before calling
SaveChangesAsync, it will cancel the transaction if it exists and closes the connection. So,
SaveChangesAsync is now mandatory to mimic the EF behavior.
So, if you have modules that use the session, you need now to call
SaveChangesAsync, otherwise, nothing will be saved. But you should not have any module that calls
And that's not all! If you would like to know every new feature and performance improvement included in YesSql 3, don't forget to check out the following recording on YouTube!
News from the community
Orchard Dojo Newsletter
Lombiq's Orchard Dojo Newsletter has 199 subscribers! We have started this newsletter to inform the community around Orchard with the latest news about the platform. By subscribing to this newsletter, you will get an e-mail whenever a new post is published to Orchard Dojo, including This week in Orchard of course.
Do you know of other Orchard enthusiasts who you think would like to read our weekly articles? Tell them to subscribe here!