I've added Lucene.Net to a .Net 6 Core project and indexing docs with TextField, StringFiled, and Int32Field all work fine but FloatField doesn't seem to be supported. I'm using LuceneVersion.LUCENE_48. According to https://lucene.apache.org/core/4_1_0/core/org/apache/lucene/document/FloatField.html, FloatField has been available since version 4.1 of Java Lucene. What am I missing? Thanks
See the Lucene.NET 4.8.0 migration guide. Numeric types and method names including numeric types have been changed to use .NET conventions.
Instead of Float use Single. Note that Lucene.Net.Queries.Function.ValueSources.SingleFunction was renamed Lucene.Net.Queries.Function.ValueSources.SingularFunction to distinguish it from the System.Single data type.
So, FloatField has been renamed to SingleField.
With the release of the .TagWithCallSite() method in EF Core 6.0 I was wondering if there is a way to apply this globally on every query run via a DbContext in some way?
It would be much better to apply this across the whole project without having to put it on each query individually.
TagWithCallSite accepts parameters marked with CallerFilePathAttribute and CallerLineNumberAttribute which are filled in by compiler (or manually if needed) during build so it is impossible to set up globally.
No, you cant't do that.
When you explicitly define TagWithCallSite(), complier automatically fills default parameters filePath and lineNumber. It is not possible to define that for all queries because compiler do not store such information in Expression Tree.
I use the following stored procedure to maintain the edit time on a few tables via triggers on those tables:
CREATE OR REPLACE FUNCTION maintain_edit_time()
RETURNS TRIGGER AS $t_edit_time$
BEGIN
NEW.edit_timestamp = NOW();
RETURN NEW;
END;
$t_edit_time$ LANGUAGE plpgsql;
When generating jOOQ objects for the database in question, I get the following generated code:
/**
* #deprecated Unknown data type. Please define an explicit {#link org.jooq.Binding} to specify how this type should be handled. Deprecation can be turned off using <deprecationOnUnknownTypes/> in your code generator configuration.
*/
#java.lang.Deprecated
public static Object maintainEditTime(Configuration configuration) {
MaintainEditTime f = new MaintainEditTime();
f.execute(configuration);
return f.getReturnValue();
}
/**
* #deprecated Unknown data type. Please define an explicit {#link org.jooq.Binding} to specify how this type should be handled. Deprecation can be turned off using <deprecationOnUnknownTypes/> in your code generator configuration.
*/
#java.lang.Deprecated
public static Field<Object> maintainEditTime() {
MaintainEditTime f = new MaintainEditTime();
return f.asField();
}
I assume this is because I do not have a jOOQ binding between TRIGGER and a Java object. However, I do not have a clue what I would define this binding as, nor do I have any need for a binding to exist.
Left alone, though, this generates a compile warning. What's the cleanest, easiest way to resolve this?
Options seem to include turning off deprecation, using ignoreProcedureReturnValues, or creating a binding. Ideally, I'd like to simply not generate a Java object for this procedure, but I could not find a way to do that.
Using ignoreProcedureReturnValues globally effects the project just because of this, which is fine for now, I don't have other procedures at all, much less others with a return value. But, I hate to limit future use. Also, I'm unclear one what the comment "This feature is deprecated as of jOOQ 3.6.0 and will be removed again in jOOQ 4.0." means on the jOOQ site under this flag. Is the flag going away, or is support for stored procedure return types going away? A brief dig through the jOOQ github issues didn't yield me an answer.
Tempted to simply turn off deprecation. This also seems like a global and not beneficial change, but it would serve the purpose.
If I created a binding, I have no idea what it would do, or how to define it since TRIGGER really isn't a sensible thing to bind a Java object to. I assume I'd specify as TRIGGER in the forcedType element, but then the Java binding seems like a waste of time at best and misleading at worst.
You've already found the perfect solution, which you documented in your own answer. I'll answer your various other questions here, for completeness' sake
Using ignoreProcedureReturnValues globally effects the project just because of this, which is fine for now, I don't have other procedures at all, much less others with a return value. But, I hate to limit future use. Also, I'm unclear one what the comment "This feature is deprecated as of jOOQ 3.6.0 and will be removed again in jOOQ 4.0." means on the jOOQ site under this flag. Is the flag going away, or is support for stored procedure return types going away? A brief dig through the jOOQ github issues didn't yield me an answer.
That flag has been introduced because of a backwards incompatible change in the code generator that affected only SQL Server: https://github.com/jOOQ/jOOQ/issues/4106
In SQL Server, procedures always return an INT value, just like functions. This change allowed for fetching this INT value using jOOQ generated code. In some cases, it was desireable to not have this feature enabled when upgrading from jOOQ 3.5 to 3.6. Going forward, we'll always generate this INT return type on SQL Server stored procedures.
This is why the flag has been deprecated from the beginning, as we don't encourage its use, except for backwards compatibility usage. It probably won't help you here.
Stored procedure support is definitely not going to be deprecated.
Tempted to simply turn off deprecation. This also seems like a global and not beneficial change, but it would serve the purpose.
Why not. A quick workaround. You don't have to use all the generated code. The deprecation is there to indicate that calling this generated procedure probably won't work out of the box, so its use is discouraged.
If I created a binding, I have no idea what it would do, or how to define it since TRIGGER really isn't a sensible thing to bind a Java object to. I assume I'd specify as TRIGGER in the forcedType element, but then the Java binding seems like a waste of time at best and misleading at worst.
Indeed, that wouldn't really add much value to your use cases as you will never directly call the trigger function in PostgreSQL.
Again, your own solution using <exclude> is the ideal solution here. In the future, we might offer a new code generation configuration flag that allows for turning on/off the generation of trigger functions, with the default being off: https://github.com/jOOQ/jOOQ/issues/9270
Well, after noting that an ideal way to do this would be to ignore that procedure, I did find how to ignore the procedure by name in the generally excellent jOOQ website documentation. Don't know how I missed in on first pass. If I needed to call this procedure in Java, I'm unclear which of the above options I would have used.
Luckily, there was no need for this procedure to be referenced in code, and I excluded it as shown below in in the jOOQ XML configuration.
<excludes>
databasechangelog.*
| maintain_edit_time
</excludes>
The MongoEnvironmentSetter#setLatencySmoothFactor method updates the system property com.mongodb.latencySmoothFactor and it isn't available since 2.12.0 ( related git hashes 0375c984fccf9cb0868b406c145f8fd3e263348c 1ae976fa2342cdddeade622f293dc3fccbb80a58). I found the following tickets related to that:
https://jira.mongodb.org/browse/JAVA-763
https://jira.mongodb.org/browse/JAVA-786
https://jira.mongodb.org/browse/JAVA-859
https://jira.mongodb.org/browse/JAVA-930
https://jira.mongodb.org/browse/JAVA-931
But I didn't find the equivalence to this property. Any thoughts? Which are the steps to do in a migration if some application has configured this property?
There is no equivalent in 2.12, as the driver no longer performs any smoothing of round-trip times. Smoothing may be added in a future release, but most likely it won't be configurable. I'm not sure what the MongoEnvironmentSetter is, but assuming this is something you control, your best option is to ignore that property or remove it.
I am working my way through the Hands-On-Labs for reactive extensions (Rx HOL .NET.pdf) which I downloaded from the data developer center (here) a few days ago.
I added these references to my project, using NuGet:
System.Reactive 1.0.10621.0
System.Reactive.Windows.Forms 1.0.10621.0
I'm almost done with the labs, but I've hit a snag trying to implement the .Switch() example, Visual Studio can't locate the extension method:
'System.IObservable'
does not contain a definition for
'Switch' and no extension method
'Switch' accepting a first argument of
type
'System.IObservable'
could be found (are you missing a
using directive or an assembly
reference?)
Now I know this Hands On Labs document is out of date, because certain things have been renamed (FromEvent became FromEventPattern) and certain things were removed (RemoveTimeStamp) and this document does not reflect that. For the life of me I cannot guess what they renamed Switch to be, or figure out what assembly they might have moved it to, or find a comprehensive list of release notes that indicate it was removed.
Anyone know where I can find Switch and what it's current name is?
The Switch extension method doesn't extend IObservable<T> - it extends IObservable<IObservable<T>>. The full signature is:
IObservable<TSource> Switch<TSource>(this IObservable<IObservable<TSource>> sources)
Try typing Observable.Empty<IObservable<object>>(). and see if Switch appears then.
If not, check your using namespace declarations.