I'm trying to create a query like:
INSERT INTO users (id, level)
VALUES (1, 0)
ON CONFLICT (id) DO UPDATE
SET level = users.level + 1;
However I can't see how to do this with opaleye? Is this not supported?
Strangely we have Insert defined with a field of iOnConflict :: Maybe OnConflict. However OnConflict is defined as: data OnConflict = DoNothing so it just looks like a placeholder for now?
Following through the issue listed on github, I see it leads to this eventual PR: https://github.com/tomjaguarpaw/haskell-opaleye/pull/385/files but I can't really make sense of it? I'm not sure if it's implementing just the placeholder, or it actually implements the functionality.
Firstly, you will generally get a quicker, and probably better, response to these kinds of questions if you
file a new issue on the Opaleye repo.
Opaleye currently only supports ON CONFLICT DO NOTHING. I'm happy to look into supporting more functionality though. Please chime in with a new issue or on a relevant existing one.
Related
When generating code using JOOQ for a SQL Server database the generation creates three-part qualifiers like: [catalog].[schema].[table]. This is exactly what I want when working with the SQL Server databases but is an issue when using the generated code with another database like an H2 in memory database for unit testing.
The H2 dialect does not support these three-part qualifiers, H2 expects something like [catalog].[table]. This causes syntax errors when executing commands like the following against H2:
context.createTable(TBLBUSINESSENTITY).columns(TBLBUSINESSENTITY.fields()).execute();
To solve this I need to change the qualifier at runtime which I thought could be done using a render mapping and mapped schema. Unfortunately, this seems to only have the ability to modify the schema portion of the qualifier like this:
Settings settings = new Settings().withRenderMapping(new RenderMapping().withSchemata(
new MappedSchema().withInput("dbo").withOutput("mySchema")));
Given the qualifier [MyDatabase].[dbo].[MyTable], this maps to [MyDatabase].[mySchema].[MyTable] but I cant figure out how to remove that section entirely.
Is there some way to rewrite the mapping to [MyDatabase].[MyTable]?
Use this setting instead:
Settings settings = new Settings()
.withRenderCatalog(false)
.withRenderMapping(new RenderMapping()
.withCatalogs(new MappedCatalog()
.withInput("MyDatabase")
.withSchemata(new MappedSchema()
.withInput("dbo")
.withOutput("MyDatabase"))));
Cassandra has org.apache.cassandra.cql3.QueryHandler interface which provide apis to handle external queries from client.
Below api which handles prepared statment:
public ResultMessage processPrepared(CQLStatement statement, QueryState state, QueryOptions options) throws RequestExecutionException, RequestValidationException;
I want to log queryString and value passed to it, in case CQLStatement,QueryState and QueryOptions is given . How can i get it?
I Believe a person who has worked on cassandra code can help me out in this.
This would be very difficult in 2.1. With newer versions where for logging they needed this they just recreate it as well as possible. You can see how in the ReadCommand implementations, theres a name() or toCQLString() used in things like slow query logging. You could backport this and the 2 implementations of appendCQLWhereClause for ability to do similar and then build one for modification statement.
in getPrepared() you can get the rawCQLStatement from the ParsedStatement.Prepared and stash it in the thread local.
You may want to alternatively consider using a custom implementation of tracing (example) or using triggers and building a mutation logger.
Do the following:
create a class that would implement the QueryHandler interface and make Cassandra aware of it
in that class you can maintain a list of the queries (add to this list when prepare method is being called) and the current query that you will get from the list when getPrepared it's called; you can get it from the list using the MD5Digest id
when processPrepared is called you can replace the ? in the query string with the values in the QueryOptions options.getValues().
HTH
We have a type named OldThing which we want to deprecate over time.
We need an NDepend query/rule that says from this point on, don't add any more calls to 'OldThing'.
We currently use NDepend and have a baseline build for checking things like don't make large methods even larger.
So, we'd like to use NDepend to track any additional calls made to OldThing. I have the following CQL query:
// <Name>Don't use OldThing going forwards</Name>
warnif count > 0
let containsMethods = Methods.WithFullNameIn(
"MyNamespace.OldType.get_Foo()",
"MyNamespace.OldType.get_Bar()")
from m in Application.Methods.UsingAny(containsMethods)
where m.IsUsedRecently()
select m
... the trouble is, it doesn't seem to work; it doesn't find any new calls.
Is there a better way of doing this in NDepend (perhaps by utilising trend metrics)?
You don't need where m.IsUsedRecently(), this is only for third-party method calls.
Then you need to double check that the let expression is matching the proper deprecated methods (you could also match them all at once by using the ObsoleteAttribute).
Finally you should make this rule critical and it should work :)
I am wondering if there is a way to ignore certain TypeScript errors upon compilation?
I basically have the same issues most people with large projects have around using the this keyword, and I don't want to put all my classes methods into the constructor.
So I have got an example like so:
TypeScript Example
Which seems to create perfectly valid JS and allows me to get around the this keyword issue, however as you can see in the example the typescript compiler tells me that I cannot compile that code as the keyword this is not valid within that scope. However I don't see why it is an error as it produces okay code.
So is there a way to tell it to ignore certain errors? I am sure given time there will be a nice way to manage the this keyword, but currently I find it pretty dire.
== Edit ==
(Do not read unless you care about context of this question and partial rant)
Just to add some context to all this to show that I'm not just some nut-job (I am sure a lot of you will still think I am) and that I have some good reasons why I want to be able to allow these errors to go through.
Here are some previous questions I have made which highlight some major problems (imo) with TypeScript current this implementation.
Using lawnchair with Typescript
Issue with child scoping of this in Typescript
https://typescript.codeplex.com/discussions/429350 (And some comments I make down the bottom)
The underlying problem I have is that I need to guarantee that all logic is within a consistent scope, I need to be able to access things within knockout, jQuery etc and the local instance of a class. I used to do this with the var self = this; within the class declaration in JavaScript and worked great. As mentioned in some of these previous questions I cannot do that now, so the only way I can guarantee the scope is to use lambda methods, and the only way I can define one of these as a method within a class is within the constructor, and this part is HEAVILY down to personal preference, but I find it horrific that people seem to think that using that syntax is classed as a recommended pattern and not just a work around.
I know TypeScript is in alpha phase and a lot will change, and I HOPE so much that we get some nicer way to deal with this but currently I either make everything a huge mess just to get typescript working (and this is within Hundreds of files which I'm migrating over to TypeScript ) or I just make the call that I know better than the compiler in this case (VERY DANGEROUS I KNOW) so I can keep my code nice and hopefully when a better pattern comes out for handling this I can migrate it then.
Also just on a side note I know a lot of people are loving the fact that TypeScript is embracing and trying to stay as close to the new JavaScript features and known syntax as possible which is great, but typescript is NOT the next version of JavaScript so I don't see a problem with adding some syntactic sugar to the language as people who want to use the latest and greatest official JavaScript implementation can still do so.
The author's specific issue with this seems to be solved but the question is posed about ignoring errors, and for those who end up here looking how to ignore errors:
If properly fixing the error or using more decent workarounds like already suggested here are not an option, as of TypeScript 2.6 (released on Oct 31, 2017), now there is a way to ignore all errors from a specific line using // #ts-ignore comments before the target line.
The mendtioned documentation is succinct enough, but to recap:
// #ts-ignore
const s : string = false
disables error reporting for this line.
However, this should only be used as a last resort when fixing the error or using hacks like (x as any) is much more trouble than losing all type checking for a line.
As for specifying certain errors, the current (mid-2018) state is discussed here, in Design Meeting Notes (2/16/2018) and further comments, which is basically
"no conclusion yet"
and strong opposition to introducing this fine tuning.
I think your question as posed is an XY problem. What you're going for is how can I ensure that some of my class methods are guaranteed to have a correct this context?
For that problem, I would propose this solution:
class LambdaMethods {
constructor(private message: string) {
this.DoSomething = this.DoSomething.bind(this);
}
public DoSomething() {
alert(this.message);
}
}
This has several benefits.
First, you're being explicit about what's going on. Most programmers are probably not going to understand the subtle semantics about what the difference between the member and method syntax are in terms of codegen.
Second, it makes it very clear, from looking at the constructor, which methods are going to have a guaranteed this context. Critically, from a performance, perspective, you don't want to write all your methods this way, just the ones that absolutely need it.
Finally, it preserves the OOP semantics of the class. You'll actually be able to use super.DoSomething from a derived class implementation of DoSomething.
I'm sure you're aware of the standard form of defining a function without the arrow notation. There's another TypeScript expression that generates the exact same code but without the compile error:
class LambdaMethods {
private message: string;
public DoSomething: () => void;
constructor(message: string) {
this.message = message;
this.DoSomething = () => { alert(this.message); };
}
}
So why is this legal and the other one isn't? Well according to the spec: an arrow function expression preserves the this of its enclosing context. So it preserves the meaning of this from the scope it was declared. But declaring a function at the class level this doesn't actually have a meaning.
Here's an example that's wrong for the exact same reason that might be more clear:
class LambdaMethods {
private message: string;
constructor(message: string) {
this.message = message;
}
var a = this.message; // can't do this
}
The way that initializer works by being combined with the constructor is an implementation detail that can't be relied upon. It could change.
I am sure given time there will be a nice way to manage the this keyword, but currently I find it pretty dire.
One of the high-level goals (that I love) in TypeScript is to extend the JavaScript language and work with it, not fight it. How this operates is tricky but worth learning.
Some time recently, I heard someone espousing the fact that a domain model should not allow updating the domain objects via properties with a subsequent Save call. But rather all updates should be done through explicit methods. Example of how I understand what was said:
Bad Code (that seems pretty normal to me):
var x = _repository.GetCustomerByID(5);
x.Firstname = "Travis";
x.Lastname = "Laborde";
_respository.SaveCustomer(x);
The Code that I believe this person was pitching would look like:
var x = _repository.GetCustomerByID(5);
x.UpdateCustomerName("Travis", "Laborde");
_repository.SaveCustomer(x);
I'd like to learn more - is there a name to this pattern so that I can Google it on Bing?
I'm not aware of this pattern having a specific name, but from what you describe, there's a basic practical reason for this:
Writing x.Firstname = "Travis" does not let the x object know that the Firstname value was changed. This makes it hard to implement a SaveCustomer function that only uses UPDATE on the fields that were changed.
Of course, in a language that does support treating member assignment as a function call (like, say, C# does with its properties), this pattern becomes much less interesting.