I have a question about assembly process of RxJava2. What is the main purpose of this process? When is attribute onObservableAssembly (RxJavaPlugins) set to null or to reference? And is possible to watch implementation of functional interface with apply method which is used in onAssembly method? You can explain case with Observable.just(1,2,3) and with filter. Thanks
The assembly process is when operator chains are established to form a template for the dataflow realized later via a subscribe() call. Assembly hooks are advanced concepts, typically not needed by most users, to inject custom operators when the static/final methods of Observable are called.
Use cases could be:
Adding debug operators that capture the current stacktrace when the assembly happened, possibly giving extra information where to look in case of crashes.
Replacing specific operators with other custom operators.
Shimming custom operators that validate the flow for protocol adherence.
The default assembly hooks are null which means the originally intended operators will carry on.
Example usages can be found in the extensions project. With just and filter, you could do such things:
RxJavaPlugins.setOnObservableAssembly(o -> {
if (o instanceof ObservableFromArray) {
return new ObservableFromArray<>(new Integer[] { 4, 5, 6 });
}
return o;
});
Observable.just(1, 2, 3)
.filter(v -> v > 3)
.test()
.assertResult(4, 5, 6);
RxJavaPlugins.setOnObservableAssembly(null);
Related
I am trying to explore the reactive programming using drools. I am doing POC to apply the drools rules on the object.
public Mono<Order> findByOrderNo(String orderNo) {
Mono<Order> order = orderDAO.findByOrderNo ( orderNo );
KieSession kieSession = kieContainer.newKieSession("rulesSessionpart2");
kieSession.insert(order); // rules are not getting applied as it requires the object type
//as input
kieSession.fireAllRules();
kieSession.dispose();
return order;
}
This is my test rule:
import com.reactive.practice.springreactor.model.Order
rule "ReturnEligible for Order"
when
orderObject: Order(itemReturnEligible==true)
then
orderObject.setDescription("bdfgdfdfhdf");
end
Here the method kieSession.insert(order) requires an object as input, but in the above code, I am passing Publisher type of Mono.
I tried converting Mono to Order object using block(). As in many documentation suggests it is not recommendable to use as it is blocking the operation.
Is there any other way to convert the Mono to Order Object.
Any help is appreciable.
Thanks
Two answers
1) Use a dedicated testing library like reactor-test
https://projectreactor.io/docs/core/release/reference/#testing
StepVerifier.create(
appendBoomError(source))
.expectNext("thing1")
.expectNext("thing2")
.expectErrorMessage("boom")
.verify();
2) Calling block in a test isn't a problem.
If you unit test method is blocking and must complete before you return then block is arguably the right call to make. But there are still better ways to do this like StepVerifier above.
In reactive style programming, calling block in your production code is almost always a bug unless you are specifically the framework code in a blocking context (e.g. a synchronous servlet API that runs the process). Generally you return a Mono and transform other inputs without having a blocking call.
I'm constructing and executing my queries in a way that's independent of EF-Core, so I'm relying on IQueryable<T> to obtain the required level of abstraction. I'm replacing awaited SingleAsync() calls with awaited ToAsyncEnumerable().Single() calls. I'm also replacing ToListAsync() calls with ToAsyncEnumerable().ToList() calls. But I just happened upon the ToAsyncEnumerable() method so I'm unsure I'm using it correctly or not.
To clarify which extension methods I'm referring to, they're defined as follows:
SingleAsync and ToListAsync are defined on the EntityFrameworkQueryableExtensions class in the Microsoft.EntityFrameworkCore namespace and assembly.
ToAsyncEnumerable is defined on the AsyncEnumerable class in the System.Linq namespace in the System.Interactive.Async assembly.
When the query runs against EF-Core, are the calls ToAsyncEnumerable().Single()/ToList() versus SingleAsync()/ToListAsync() equivalent in function and performance? If not then how do they differ?
For methods returning sequence (like ToListAsync, ToArrayAsync) I don't expect a difference.
However for single value returning methods (the async versions of First, FirstOrDefault, Single, Min, Max, Sum etc.) definitely there will be a difference. It's the same as the difference by executing those methods on IQueryable<T> vs IEnumerable<T>. In the former case they are processed by database query returning a single value to the client while in the later the whole result set will be returned to the client and processed in memory.
So, while in general the idea of abstracting EF Core is good, it will cause performance issues with IQueryable<T> because the async processing of queryables is not standartized, and converting to IEnumerable<T> changes the execution context, hence the implementation of single value returning LINQ methods.
P.S. By standardization I mean the following. The synchronous processing of IQueryable is provided by IQueryProvider (standard interface from System.Linq namespace in System.Core.dll assembly) Execute methods. Asynchronous processing would require introducing another standard interface similar to EF Core custom IAsyncQueryProvider (inside Microsoft.EntityFrameworkCore.Query.Internal namespace in Microsoft.EntityFrameworkCore.dll assembly). Which I guess requires cooperation/approval from the BCL team and takes time, that's why they decided to take a custom path for now.
When the original source is a DbSet, ToAsyncEnumerable().Single() is not as performant as SingleAsync() in the exceptional case where the database contains more than one matching row. But in in the more likely scenario, where you both expect and receive only one row, it's the same. Compare the generated SQL:
SingleAsync():
SELECT TOP(2) [l].[ID]
FROM [Ls] AS [l]
ToAsyncEnumerable().Single():
SELECT [l].[ID]
FROM [Ls] AS [l]
ToAsyncEnumerable() breaks the IQueryable call chain and enters LINQ-to-Objects land. Any downstream filtering occurs in memory. You can mitigate this problem by doing your filtering upstream. So instead of:
ToAsyncEnumerable().Single( l => l.Something == "foo" ):
SELECT [l].[ID], [l].[Something]
FROM [Ls] AS [l]
you can do:
Where( l => l.Something == "foo" ).ToAsyncEnumerable().Single():
SELECT [l].[ID], [l].[Something]
FROM [Ls] AS [l]
WHERE [l].[Something] = N'foo'
If that approach still leaves you squirmish then, as an alternative, consider defining extension methods like this one:
using System.Linq;
using System.Threading.Tasks;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Query.Internal;
static class Extensions
{
public static Task<T> SingleAsync<T>( this IQueryable<T> source ) =>
source.Provider is IAsyncQueryProvider
? EntityFrameworkQueryableExtensions.SingleAsync( source )
: Task.FromResult( source.Single() );
}
According to the official Microsoft documentation for EF Core (all versions, including the current 2.1 one):
This API supports the Entity Framework Core infrastructure and is not intended to be used directly from your code. This API may change or be removed in future releases.
Source: https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.query.internal.asynclinqoperatorprovider.toasyncenumerable?view=efcore-2.1
p.s. I personally found it problematic in combination with the AutoMapper tool (at least, until ver. 6.2.2) - it just doesn't map collection of type IAsyncEnumerable (unlike IEnumerable, with which the AutoMapper works seamlessly).
I took a peek at the source code of Single (Line 90).
It cleary illustrates that the enumerator is only advanced once (for a successful operation).
using (var e = source.GetEnumerator())
{
if (!await e.MoveNext(cancellationToken)
.ConfigureAwait(false))
{
throw new InvalidOperationException(Strings.NO_ELEMENTS);
}
var result = e.Current;
if (await e.MoveNext(cancellationToken)
.ConfigureAwait(false))
{
throw new InvalidOperationException(Strings.MORE_THAN_ONE_ELEMENT);
}
return result;
}
Since this kind of implementation is as good as it gets (nowadays), one can say with certainty that using the Ix Single Operator would not harm performance.
As for SingleAsync, you can be sure that it is implemented in a similar manner, and even if it is not (which is doubtful), it could not outperform the Ix Single operator.
I'm very new to the Swift language.
I wanted to declare an inline function just like in C++
so my func declaration looks like this:
func MyFunction(param: Int) -> Int {
...
}
and I want to do something like this:
inline func MyFunction(param: Int) -> Int {
...
}
I tried to search on the web but I didn't find anything relevant maybe there is no inline keyword but maybe there is another way to inline the function in Swift.
Swift 1.2 will include the #inline attribute, with never and __always as parameters. For more info, see here.
As stated before, you rarely need to declare a function explicitly as #inline(__always) because Swift is fairly smart as to when to inline a function. Not having a function inlined, however, can be necessary in some code.
Swift-5 added the #inlinable attribute, which helps ensuring that library/framework stuff are inlineable for those that link to your library. Make sure you read up about it, as there may be a couple of gotchas that might make it unusable. It's also only for functions/methods declared public, as it's meant for libraries wanting to expose inline stuff.
All credit to the answer, just summarizing the information from the link.
To make a function inline just add #inline(__always) before the function:
#inline(__always) func myFunction() {
}
However, it's worth considering and learning about the different possibilities. There are three possible ways to inline:
sometimes - will make sure to sometimes inline the function. This is the default behavior, you don't have to do anything! Swift compiler might automatically inline functions as an optimization.
always - will make sure to always inline the function. Achieve this behavior by adding #inline(__always) before the function. Use "if your function is rather small and you would prefer your app ran faster."
never - will make sure to never inline the function. This can be achieved by adding #inline(never) before the function. Use "if your function is quite long and you want to avoid increasing your code segment size."
I came across an issue that i needed to use #inlinable and #usableFromInline attributes that were introduced in Swift 4.2 so i would like to share my experience with you.
Let me get straight to the issue though, Our codebase has a Analytics Facade module that links other modules.
App Target -> Analytics Facade module -> Reporting module X.
Analytics Facade module has a function called report(_ rawReport: EventSerializable) that fire the reporting calls, This function uses an instance from the reporting module X to send the reporting calls for that specific reporting module X.
The thing is, calling that report(_ rawReport: EventSerializable) function many times to send the reporting calls once the users launch the app creates unavoidable overhead that caused a lot of crashes for us.
Moreover it's not an easy task to reproduce these crashes if you are setting the Optimisation level to None on the debug mode. In my case i was able only to reproduce it when i set the Optimisation level to Fastest, Smallest or even higher.
The solution was to use #inlinable and #usableFromInline.
Using #inlinable and #usableFromInline export the body of a function as part of a module's interface, making it available to the optimiser when referenced from other modules.
The #usableFromInline attribute marks an internal declaration as being part of the binary interface of a module, allowing it to be used from #inlinable code without exposing it as part of the module's source interface.
Across module boundaries, runtime generics introduce unavoidable overhead, as reified type metadata must be passed between functions, and various indirect access patterns must be used to manipulate values of generic type. For most applications, this overhead is negligible compared to the actual work performed by the code itself.
A client binary built against this framework can call those generics functions and enjoy a possible performance improvement when built with optimisations enabled, due to the elimination of abstraction overhead.
Sample Code:
#inlinable public func allEqual<T>(_ seq: T) -> Bool
where T : Sequence, T.Element : Equatable {
var iter = seq.makeIterator()
guard let first = iter.next() else { return true }
func rec(_ iter: inout T.Iterator) -> Bool {
guard let next = iter.next() else { return true }
return next == first && rec(&iter)
}
return rec(&iter)
}
More Info - Cross-module inlining and specialization
I created a sample project and a framework next to it. The framework is called "SampleFramework". Then I created a custom operator in SampleFramework. Here is what it looks like:
infix operator >>= {associativity left}
public func >>=<A, B>(a: A?, f: A -> B?) -> B? {
if let a = a { return f(a) }
else { return .None }
}
Then I wanted to use it my main application. I imported the SampleFramework to my source file and then I wrote this code to test it:
NSURL(string: "www.google.com") >>= { println("\($0)") }
It didn't compile. Here is Xcode's error message:
Ambiguous operator declarations found for operator. Operator is not a
known binary operator
I can confirm that that what you are seeing is what really happens. I just tried it myself and I've seen the same result.
My opinion is that >>= is somehow conflicting with some other operator (probably the bite shift operator: >>) or is being declared somewhere else too (you can see why I think that here). I did successfully declared custom operators in a framework and used those in the main app code before (you can see that here for example).
What I would suggest is rename your custom operator to something else. When I did that (renamed the custom operator to >>>=) the compiler stopped complaining and my app compiled just fine.
Later edit
Ok. So this might help a bit more. Basically when an operator is already declared and you want to add extra functionality to that operator (for example doing things like 3 * "Hello" like Johan Kool said he wanted to) all you have to do is overload that operator's method.
Basically, in your specific case I am now 100% that >>= is an already declared operator and you can go ahead and just add these lines in your framework:
public func >>=<A, B>(a: A?, f: A -> B?) -> B? {
if let a = a { return f(a) }
else { return .None }
}
This will make your operator work. BUT it will inherit the precedence and associativity of the original operator thus giving you less control over how it's supposed to behave.
I figured it out. I think declaration of operator (infix operator >>= {associativity left}) is module specific. You can't apply access control to it. But the operator function can be accessed in other modules. So in order to make this work I had to copy operator declaration and paste it to main project.
It seems to be sufficient to just add the
infix operator + : Additive
in each source where you want to apply your framework-defined operator, assuming that your framework has some
public func + (lhs: ...
declared.
Anyhow, it's nasty to have the need for adding this if you use a framework and I'd like to see some way to have some global approach where importing a framework also makes available the operators automatically.
Edit After fiddling around for hours, the problem went away. I have not figured out what's the cause. I had lots of infix declarations in my basic framework (for historic reason). Once I got rid of them, everything went to normal. So now that I have only infix for the new operators, it's fine. But obviously re-declaring existing ones (like *, +, etc.) Swift seems to get hick-ups.
When working with dependency resolution in gradle, you usually see something like this:
configurations {
optional
compile
runtime.extendsFrom compile
testCompile.extendsFrom runtime
}
and I wanted to know of what type is optional or compile? Is it a Class? a string? what methods can I call for it?
Besides all this, is there a way to find out these things automatically, similar to ctrl+space when on something in eclipse?
They are classes that implements org.gradle.api.artifacts.Configuration. The Gradle DSL doc also contains more information about the configuration DSL core type.
To find out more info about internal classes etc, which is useful when for instance looking up classes and methods in the Gradle javadoc, it is often as simple as just printing out the class names. Quite often though, you will end up with some internal implementing class instead of the API interface you're interested in, but regardless of that it's a way get started on what to search for. I tend to keep the source code of all open source projects we're using available in the IDE. That way it's easy to jump into the correct class (even when it's not available through context shortcuts) and look around.
To get more information about configurations in your case, you could add a task that simply prints out the relevant info. E.g. something like:
task configInfo << {
println "configurations.class: ${configurations.class}"
println "configurations.compile class: ${configurations.compile.class}"
println "implements ${Configuration} interface? ${configurations.compile instanceof Configuration}"
}
which in my case results in the following output
$ gradle configInfo
:configInfo
configurations.class: class org.gradle.api.internal.artifacts.configurations.DefaultConfigurationContainer_Decorated
configurations.compile class: class org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated
implements interface org.gradle.api.artifacts.Configuration interface? true
I am no Gradle expert, but this seems like a simple getter delegated to another object in a DSL fashion. You could write the same with something like this:
class MyDsl {
def config = [:].withDefault { false }
void configure(closure) {
closure.delegate = this
closure()
}
def getOptional() { config.optional = true }
def getCompile() { config.compile = true }
def getTest() { config.test = true }
}
dsl = new MyDsl()
dsl.configure {
optional
compile
}
dsl.config.with {
assert optional
assert compile
assert !test
}
You could return some specific object to pass to runtime.extendsFrom() method.
For auto-complete, IIRC that's what groovy-eclipse DSLD (DSL descriptors) are for. You may want to give a try to this gradle DSLD which is in eclipse-integration-gradle plugin.
As per this ticket it has been done long ago.
The question "what type is optional or compile" isn't really valid. That is kind of like asking what type does "instanceof" have. The instanceof keywword doesn't have a type.
When writing code like you cited, you are taking advantage of a DSL. Treat words like compile and optional as keywords in that DSL. Unless you are writing your own DSL (as opposed to taking advantage of existing one, which is what this question is about), don't think of types being associated with those things.
As for the question about ctrl+space, Eclipse won't do anything special with that in this context unless you are using a plugin which provides support for that. Even with plugin support there will still be limitations because you can define your own configurations. If you were going to define a configuration named "jeffrey" and you typed "jeff" followed by ctrl+space, there is no way for the IDE to know you want it to turn that into "jeffrey".
I hope that helps.