Typings don't allow custom query builders

I'm trying to create Model, which has extended query builder with .session() method. However when I'm extending the model and setting our custom query builder there return type of $query() and other functions still is QueryBuilder<this> instead of CustomQueryBuilder<this>.
Simplified (not runnable example):
class CustomQueryBuilder<T> extends QueryBuilder<T> {
  session(session: any) {
    this.context().session = session;
    return this;
  }
}

class BaseModel extends Model {
  // Override the objection.js query builders classes for subclasses.
  static QueryBuilder = CustomQueryBuilder;
  static RelatedQueryBuilder = CustomQueryBuilder;

  // ... more stuff ...
}

const daa = await BaseModel
          .query(trx)
          // ERROR: [ts] Property 'session' does not exist on type 'QueryBuilder<BaseModel>'
          .session(req.session)
          .insert({1:1});

Any ideas how to override this? I wouldn't like to do casting everywhere I'm using my extended query builder, nor I would like to add extra methods to BaseModel which would apply correct typing for returned query builder.

@mceachen Could you take a look at this?

Will do.

@elhigu Can't you just do this:
class BaseModel extends Model {
  static query(...args): CustomQueryBuilder {
    return <CustomQueryBuilder>super.query(...args);
  }

  $query(...args): CustomQueryBuilder {
    return <CustomQueryBuilder>super.$query(...args);
  }

  $relatedQuery(...args): CustomQueryBuilder {
    return <CustomQueryBuilder>super.$relatedQuery(...args);
  }
}

@koskimas I tried that, but typescript tells me that those methods doesn't have correct signature :(
But this syntax I learned recently, might work also for class methods I haven't tried it yet (https://www.typescriptlang.org/docs/handbook/functions.html):

function pickCard(x: {suit: string; card: number; }[]): number;
function pickCard(x: number): {suit: string; card: number; };
function pickCard(x): any {
    // Check to see if we're working with an object/array
    // if so, they gave us the deck and we'll pick the card
    if (typeof x == "object") {
        let pickedCard = Math.floor(Math.random() * x.length);
        return pickedCard;
    }
    // Otherwise just let them pick the card
    else if (typeof x == "number") {
        let pickedSuit = Math.floor(x / 13);
        return { suit: suits[pickedSuit], card: x % 13 };
    }
}

@elhigu I was able to get the static query function definition to work. Try changing the example given by @koskimas to
class BaseModel extends Model {
  static query(trx? : Transaction): CustomQueryBuilder {
    return super.query.call(this, trx) as CustomQueryBuilder;
  }
}

Haven't played with it too much, but the typescript does compile at least.
Haven't figured out the $query or $relatedQuery functions yet, as those seem to require a different type of QueryBuilderSingle<this>

@tobalsgithub's approach should work, but it'd be nice if the typings "just worked" without that.
Also, be aware that you'll only have your new methods available from chained method calls that return a this (which is about half the methods). Other methods will have reverted to the default query builders.
For example, BaseModel.query().relate() will still return a CustomQueryBuilder, but BaseModel.query().insertAndFetch() will give you a QueryBuilderSingle<BaseModel>.
The only way around this that I see is introducing both generic subtypes for Model as well as generic subtypes for QueryBuilder and that hierarchical tree.

Hi, thanks everyone. I'll report back after I got a change to try out these solutions.
IMO if I get any of these working it is good enough workaround. Anyways at least for now this is quite rare use case and overriding $query etc. shouldn't be a show stopper for anyone..

@tobalsgithub I still cannot get  this stuff working, but made some progress and static method overriding seem to work already. $query is still failing, because class is extended from incompatible promise stuff or something like that. I made test project and when its working I'll add it to greenkeeper (or merge to objection codebase) to keep example working when typings are updated (https://github.com/elhigu/objection-overriding-querybuilder-typescript).
import { Model, QueryBuilder, QueryBuilderSingle, Transaction } from 'objection';

class BaseQueryBuilder<T> extends QueryBuilder<T> {
  session(session: any) {
    return this.mergeContext({ session });
  }
}

// try to override $query() method to return correct query builder
class BaseModelDollarQueryOverrideTest extends Model {
  static QueryBuilder = BaseQueryBuilder;
  static RelatedQueryBuilder = BaseQueryBuilder;

  $query(trx?: Transaction): BaseQueryBuilder<this> {
    return <any> this.$query(trx);
  }
}

// try to override static query() method to return correct query builder
class BaseModelStaticQueryOverrideTest extends Model {
  static QueryBuilder = BaseQueryBuilder;
  static RelatedQueryBuilder = BaseQueryBuilder;

  static query<T>(trx?: Transaction): BaseQueryBuilder<T> {
    return <any> super.query(trx);
  }
}

const testDollar = new BaseModelDollarQueryOverrideTest();
testDollar.$query().session({});

BaseModelStaticQueryOverrideTest.query().session({});

Current error is:
Mikaels-MacBook-Pro-2:objection-subclassing mikaelle$ npm test

><EMAIL_ADDRESS>test /Users/mikaelle/Projects/Vincit/objection-subclassing
> tsc

test.ts(10,7): error TS2415: Class 'BaseModelDollarQueryOverrideTest' incorrectly extends base class 'Model'.
  Types of property '$query' are incompatible.
    Type '(trx?: Transaction) => BaseQueryBuilder<this>' is not assignable to type '(trx?: Transaction) => QueryBuilderSingle<this>'.
      Type 'BaseQueryBuilder<this>' is not assignable to type 'QueryBuilderSingle<this>'.
        Types of property 'then' are incompatible.
          Type '<TResult1 = this[], TResult2 = never>(onfulfilled?: (value: this[]) => TResult1 | PromiseLike<TRe...' is not assignable to type '<TResult1 = this, TResult2 = never>(onfulfilled?: (value: this) => TResult1 | PromiseLike<TResult...'.
            Types of parameters 'onfulfilled' and 'onfulfilled' are incompatible.
              Types of parameters 'value' and 'value' are incompatible.
                Type 'this[]' is not assignable to type 'this'.
npm ERR! Test failed.  See above for more details.

This actually worked... just had to write interface declaration for QueryBuilderSingle mode of subclassed query builder.
import { Model, QueryBuilder, QueryBuilderBase, Transaction } from 'objection';

class BaseQueryBuilder<T> extends QueryBuilder<T> {
  session(session: any) {
    return this.mergeContext({ session });
  }
}

interface BaseQueryBuilderSingle<T> extends QueryBuilderBase<T>, Promise<T> {
  session(session: any): this;
}

// try to override $query() method to return correct query builder
class BaseModelDollarQueryOverrideTest extends Model {
  static QueryBuilder = BaseQueryBuilder;
  static RelatedQueryBuilder = BaseQueryBuilder;

  $query(trx?: Transaction): BaseQueryBuilderSingle<this> {
    return <any> this.$query(trx);
  }
}

// try to override static query() method to return correct query builder
class BaseModelStaticQueryOverrideTest extends Model {
  static QueryBuilder = BaseQueryBuilder;
  static RelatedQueryBuilder = BaseQueryBuilder;

  static query<T>(trx?: Transaction): BaseQueryBuilder<T> {
    return <any> super.query(trx);
  }
}

const testDollar = new BaseModelDollarQueryOverrideTest();
testDollar.$query().session({});

BaseModelStaticQueryOverrideTest.query().session({});

Once TypeScript supports generics with defaults (see the issue and pr), we may be able to capture the custom query builder signature into the Model generic, and not break the current typing API.

@mceachen did you ever come back to looking at this and if so, have any success?

I didn't. If you have time, I'd be happy to help review a PR though.

I need this fix as well and have been looking over how to do it. I have a proposal, but these typedefs are pretty complex, and I don't know if it'll work or how much reworking it requires.
Right now, the model class T and the query builder class QueryBuilder are both assigned via either query() or $query().
What if we instead assign them via Model's static QueryBuilder getter? That way the type of the query builder would be the type of value returned, whatever it happens to be, subject to the constraint that it extends QueryBuilder?
I'm looking into this now, but my minimal experience with Typescript type decls is making this a challenge.

This is not a long-term solution, or a pretty one, but it does work. I'm sharing it in case it triggers better ideas in others.
// typings
query<QB extends QueryBuilder<M>>(trxOrKnex?: Transaction | knex): QB;
static query<T, QB extends QueryBuilder<T>>(this: Constructor<T>, trxOrKnex?: Transaction | knex): QB;

// usage
return Model.query<ExtendedQueryBuilder<M>>().customMethod().insert(obj);

Surprisingly, no default generic is required to call query() or $query() using QueryBuilder. This works fine with the above typings:
// usage
return Model.query().insert(obj);

I think it'd help to get example code (in a branch or codepen or whatever)
that you guys want to see, and we can go from there, perhaps? Heck, maybe a
Google doc?
On Dec 18, 2017 12:39 PM, "Joe Lapp"<EMAIL_ADDRESS>wrote:

I need this fix as well and have been looking over how to do it. I have a
proposal, but these typedefs are pretty complex, and I don't know if it'll
work or how much reworking it requires.
Right now, the model class T and the query builder class QueryBuilder are
both assigned via either query() or $query().
What if we instead assign them via Model's static QueryBuilder getter?
That way the type of the query builder would be the type of value returned,
whatever it happens to be, subject to the constraint that it extends
QueryBuilder?
I'm looking into this now, but my minimal experience with Typescript type
decls is making this a challenge.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Vincit/objection.js/issues/319#issuecomment-352551111,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANNOf-iRtPD6qO6cJBGJJ_rOQYV6vO2ks5tBs2XgaJpZM4MULSv
.

Okay, I'll condense my project for us to use. I was meaning to share it in the end anyway, as I think I've found a pretty nice way to encapsulate Objection in Typescript for dependency injection. I'll post it as an example in a new GitHub repository. It'll take me a few to make it presentable.
Question: So far I've found it easiest to play with the ambient objection typings locally in my own project, instead of linking my package to a local mod of the objection repo. Should I just post that? That would give us a separate copy to play with, anyway.

Or maybe I should post it to my local objection repo as a koa-ts-di example, for possible PR later.

I opted to create a working Typescript version of @koskimas's custom QueryBuilder found in examples/plugin. The README should get you started.
It was quite a bear to carry forward the generality of the plugin, but I finally succeeded.

I've been trying to implement the custom query builder with Typescript for a several days without success. I was starting to think, that I am doing something wrong until I found this issue. From what I understand the issue comes from assigining

Yeah, sorry, per the above discussion I was unable to find a reasonable way to support custom query builders in Typescript -- or at least to get type checking with custom query builders.
To be more direct, objection does not support custom query builders in Typescript.

@koskimas do we want to add a line in the documentation pointing to this discussion, and close this?

and maybe

Official TypeScript support

should be removed in the README. It's misleading since the main feature isn't compatible.

The main feature? Really?

@koskimas Maybe I misunderstand something, but without custom query builders we can't reuse query logic without wrapping queries, we can't dynamically change the query before data are queried, etc...
I agree for very simple apps it's not an issue, but to build a real app these features are a main feature for us.
But to be clear, I don't mean to be rude or to criticize your work. It is just very frustrating to read Official typecript support and have unsupported features. I think objection should propose either :

Another way to resuse logic and customize the query builder, compatible with typescript
Have typescript support for the current query builder

Please review the demo app, written in TypeScript. No custom query builders
to be seen.
I've got a decidedly nontrivial application using objection, and don't use
custom query builders either. I've found it handy to split common queries
into functions that can apply against optional querybuilder or transaction
instances, and return the querybuilder rather than finalizing the promise,
so the functions retain chainability.
Your comment was pretty repellent (combo of both rude and wrong), fwiw.
On Tue, Jul 31, 2018, 1:52 AM Gaetan SENELLE<EMAIL_ADDRESS>wrote:

@koskimas https://github.com/koskimas Maybe I misunderstand something,
but without custom query builders we can't reuse query logic without
wrapping queries, we can't dynamically change the query before data are
queried, etc...
I agree for very simple apps it's not an issue, but to build a real app
these features are a main feature for us.
But to be clear, I don't mean to be rude or to criticize your work. It
is just very frustrating to read Official typecript support and have
unsupported features. I think objection should propose either :

Another way to resuse logic and customize the query builder,
compatible with typescript
Have typescript support for the current query builder

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Vincit/objection.js/issues/319#issuecomment-409146390,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANNOTTF5NIhk14BjBr6uu7_S3j87vUHks5uMBrLgaJpZM4MULSv
.

When I first looked at Objection, I assumed that I needed a custom query builder. I put a lot of time into trying to find a way to make it work with Typescript, but I'm glad that effort ultimately failed, because it turns out that I didn't need a custom query builder.  The .context() method provided everything I needed. (Unfortunately, I've been off on a whole 'nother project for a while, but I mean to get back.)

Any progress or working examples on this issue?

so to be clear, was it decided that you can't create custom query builders with typescript OR that you just won't get typing for them?
I can live without typings but not sure how .context could replace a custom query builder @jtlapp
If the final conclusion is that custom QBs won't be possible, I think this should definitely be added to README somewhere since this is an unfortunate landmine to discover midway through a project

so to be clear, was it decided that you can't create custom query builders with typescript OR that you just won't get typing for them?

You can cast anything to any in Typescript and use it any way you want without type support, so you can still have query builders.

I can live without typings but not sure how .context could replace a custom query builder @jtlapp

I was trying to do something that I could do using just .context(). I just wanted to auto-populate queries from session state. I'm not claiming that .context() is equivalent to a query builder.

If the final conclusion is that custom QBs won't be possible, I think this should definitely be added to README somewhere since this is an unfortunate landmine to discover midway through a project.

My 2¢: Docs should probably just say that Objection does not (and will not) provide Typescript support for query builders. The rest should be apparent to those familiar with Typescript.
I'm also thinking it would help to add a note saying that query builders are only rarely needed, that when you think to do something with a QB, first double-check whether a more appropriate mechanism already exists for the job. Maybe QB should be removed from the docs proper and moved to a plugin addendum. That might have helped me from going down the wrong track at the start.

Ah okay that makes more sense. The conversations in this issue were a bit confusing in their wording, so I wasn't sure if using it with any typings would lead to problems
So yeah I take back everything I said. Including typings for these sort of things in general is hard
Hmm I'm using QB as mixins for reusable soft deletes and search indexing. Pretty happy w my approach but I'd love to know if there's another way though

@pulse14 @alidcastano and everyone else who are pissed: The support for typing the custom query builders is not missing because we are lazy or stypid. It's missing because adding typings to them is borderline impossible. Feel free to try. People have worked hard on trying to solve this problem FOR YOU, FOR FREE, ON THEIR SPARE TIME!

People have worked hard on trying to solve this problem FOR YOU, FOR FREE, ON THEIR SPARE TIME!

And we are grateful.
This is our approach, instead of using QB methods
const query = compose(
    withSoftdelete(),
    withVersion(10)
)(this.query())

//You can change context, etc...
const withVersion = (version) => (query) => {
    return query...........
}

And for QB onBuild etc... we read context and apply our expressions. We also never use orWhere (like some other frameworks) on main query to avoid problems.

@koskimas I don't think my comment was that abrasive, but I apologize if it came off the way. I understand that this is open-source and actively contribute it myself. Heck, I released my own little framework built on top of knex/objection: https://github.com/alidcastano/druid.js
As I stated above, I had misread thread as "not being able to create a query builder" instead of "not being able to have it typed" (the former would obvs be much worse), and acknowledged that including typing for this sort of thing is hard
Once again, thanks for your work. I understand the nature of it, and I, along with many others, are grateful for Objection. 👍

@koskimas Would you consider into 2.0? It very much sounds like the problem won't be solved without involving an API break (or at least without restructuring how the types of related things work).
Alternatively, could you propose a recommended way to inject custom methods (like custom where) into query builders - our current codebase now has a tens of "as any" typecasts scattered around the codebase and our initial attempt to cleanup code with custom query methods is losing its original purpose.

I finally dipped my toes in typescript world. I was able to create this POC of custom query builders. Wouldn't it be possible to use something like this to be able to type custom query builders? Tell me what I'm missing here @elhigu @mordof @mceachen @jtlapp? This does compile:
// Objection types:

class QueryBuilder<M extends Model> extends Promise<M[]> {
  where(): this {
    return this;
  }
}

interface ModelClass<M> {
  new (): M;
}

class Model {
  static query<QB extends QueryBuilder<M>, M extends Model>(this: ModelClass<M>): QB {
    return {} as QB;
  }
}

// Your types:

class CustomQueryBuilder<M extends Model> extends QueryBuilder<M> {
  customMethod(): this {
    return this;
  }
}

class Person extends Model {
  static query<QB = CustomQueryBuilder<Person>>(): QB {
    return {} as QB;
  }
}

async function main() {
  const query = Person.query().where().customMethod().where().customMethod();
  takesPersons(await query)
}

function takesPersons(persons: Person[]) {

}

Does it work also with $query() method?

Here's the same thingy with $query
// Objection types:

class QueryBuilder<M extends Model> extends Promise<M[]> {
  where(): this {
    return this;
  }
}

interface ModelClass<M> {
  new (): M;
}

class Model {
  static query<QB extends QueryBuilder<M>, M extends Model>(this: ModelClass<M>): QB {
    return {} as QB;
  }

  $query<QB extends QueryBuilder<this>>(): QB {
    return {} as QB;
  }
}

// Your types:

class CustomQueryBuilder<M extends Model> extends QueryBuilder<M> {
  customMethod(): this {
    return this;
  }
}

class Person extends Model {
  static query<QB = CustomQueryBuilder<Person>>(): QB {
    return super.query() as any;
  }

  $query<QB = CustomQueryBuilder<Person>>(): QB {
    return {} as QB;
  }
}

async function main() {
  const query = Person.query().where().customMethod().where().customMethod();
  takesPersons(await query)

  const persons = await query;
  await persons[0].$query().customMethod().where().customMethod()
}

function takesPersons(persons: Person[]) {

}

Why would there be a problem with subqueries? Isn't that trivial to fix? Subqueries are started with the same methods. 99% of the time with static query()?

So did you try that this compiles?
const query = Person.query().where(builder => builder.customMethod());

IIRC typings did declare those builders to be normal query builders and not the custom ones.

Obviously we'd need to fix those typings :smile: None of this works with the current typings. My point was to change the current typings along these lines. I'll write an example for you that takes query builders.

Sounds really good :)

Here you go:
// Objection types:

interface Where<QB> {
  (): QB;
  // QueryBuilder<any> is correct typing here and not a workaround
  // because subqueries can be for any table (model).
  <QB extends QueryBuilder<any>>(qb: QB): QB;
}

class QueryBuilder<M extends Model> extends Promise<M[]> {
  where: Where<this>;
}

interface ModelClass<M> {
  new (): M;
}

class Model {
  static query<QB extends QueryBuilder<M>, M extends Model>(this: ModelClass<M>): QB {
    return {} as QB;
  }

  $query<QB extends QueryBuilder<this>>(): QB {
    return {} as QB;
  }
}

// Your types:

class CustomQueryBuilder<M extends Model> extends QueryBuilder<M> {
  customMethod(): this {
    return this;
  }
}

class Person extends Model {
  static query<QB = CustomQueryBuilder<Person>>(): QB {
    return super.query() as any;
  }

  $query<QB = CustomQueryBuilder<Person>>(): QB {
    return super.$query() as any;
  }
}

async function main() {
  const query = Person.query().where().customMethod().where().customMethod();
  takesPersons(await query)

  const persons = await query;
  await persons[0]
    .$query()
    .customMethod()
    .where(Person.query())
    .customMethod()
}

function takesPersons(persons: Person[]) {

}

I don't really know if we'd be able to fit all other types on top of this kind of types though... I think we'd need to simplify the types in other ways too. For example, currently QueryBuilder takes three generic type arguments. IIRC that's just a workaround for allowing the methods to be in any order. For example returning coming as the first method or the last. If we made some limitations to the order methods can be chained in typescript, we could maybe simplify them. I dunno.

If it provides better typings in other ways, then I suppose it could be good compromise. Also currently one has to decide themselves which part of chain to put to last to get correct result type (or at least earlier one had to do that... Its over a year since the last time I used objection typings).

Aaand one more update for reference for future discussions. I got the return types working with couple of generics tricks. I also added two iterfaces StaticQueryMethod and QueryMethod that make it much easier to start using custom query builders.
// Objection types:

interface CallbackVoid<T> {
  (arg: T): void
}

type ItemType<T> = T extends Array<infer R> ? R : T;
type ArrayType<T> = T extends Array<any> ? T : Array<T>

interface WhereMethod<QB> {
  (): QB;
  (cb: CallbackVoid<QB>): QB;
  <QBA extends QueryBuilder<any>>(qb: QBA): QB;
}

class QueryBuilder<M extends Model, R = M[]> extends Promise<R> {
  where: WhereMethod<this>;
}

interface DefaultStaticQueryMethod extends StaticQueryMethod<any> {
  <M extends Model, QB extends QueryBuilder<M>>(this: ModelClass<M>): QB
}

interface StaticQueryMethod<QB extends QueryBuilder<any, any>> {
  (): QB
}

interface QueryMethod<QB extends QueryBuilder<any, any>> {
  (): QB
}

interface ModelClass<M> {
  new (): M;
}

class Model {
  static query: DefaultStaticQueryMethod;
  $query: QueryMethod<QueryBuilder<this, this>>
}

// Your types:

class AnimalQueryBuilder<M extends Model, R = M[]> extends QueryBuilder<M, R> {
  customMethod(): this {
    return this;
  }
}

class Person extends Model {
  firstName: string;
}

class Animal extends Model {
  name: string;

  static query: StaticQueryMethod<AnimalQueryBuilder<Animal>>
  $query: QueryMethod<AnimalQueryBuilder<this, this>>
}

async function basic() {
  const query = Person
    .query()
    .where(Person.query())
    .where(qb => {
      qb.where()
    })

  const persons = await query;
  console.log(persons[0].firstName);

  const person = await persons[0]
    .$query()
    .where(Person.query())
    .where(qb => {
      qb.where()
    })

  console.log(person.firstName);
}

async function custom() {
  const query = Animal.query().where().where().customMethod();

  const animals = await query;
  console.log(animals[0].name)

  const animal = await animals[0]
    .$query()
    .customMethod()
    .where(qb => {
      qb.customMethod().where().customMethod()
    })
    .where(Person.query())
    .customMethod()

  console.log(animal.name)
}

Okay, that didn't work with methods that change the return value of the query builder. I believe this is impossible to solve with typescript right now... Only way I figured out is to pass around SEVEN generic types everywhere. It would be a nightmare to use and maintain. I'm giving up for now.

I think I just woke up with a solution :smile: At least for the changing return values, but I think this could be the key for the whole problem.
interface CallbackVoid<T> {
  (arg: T): void
}

interface RawBuilder {
  as(): this;
}

interface LiteralBuilder {
  castText(): this;
}

interface ReferenceBuilder {
  castText(): this;
}

function raw(sql: string, bindings?: Array<any>): RawBuilder {
  return notImplemented();
}

type Raw = RawBuilder
type Operator = string;

type NonLiteralValue = Raw
  | ReferenceBuilder
  | LiteralBuilder
  | QueryBuilder<any, any>;

type Identifier = string
  | Raw
  | ReferenceBuilder;

type Value = NonLiteralValue
  | string
  | number
  | boolean
  | Date
  | string[]
  | number[]
  | boolean[]
  | Date[]
  | null
  | Buffer

/**
 * Type for keys of non-function properties of T.
 */
type NonFunctionPropertyNames<T> = {
  [K in keyof T]: T[K] extends Function ? never : K
}[keyof T];

/**
 * Given a model type, returns the equivalent POJO type.
 */
type Pojo<T> = {
  [K in NonFunctionPropertyNames<T>]: T[K] | NonLiteralValue
}

/**
 * Just like Pojo<M> but all properties are optional.
 */
type PartialPojo<M> = Partial<Pojo<M>> & object;

/**
 * Extracts the model type from a query builder type QB.
 */
type ModelType<QB> = QB extends QueryBuilder<infer M> ? M : never;

/**
 * Extracts the property names of the query builder's model class.
 */
type ModelProps<QB> = NonFunctionPropertyNames<ModelType<QB>>

/**
 * Gets the single item query builder type for a query builder.
 */
type SQB<QB extends QueryBuilder<any, any>> = QB['SQB']

/**
 * Gets the multi-item query builder type for a query builder.
 */
type AQB<QB extends QueryBuilder<any, any>> = QB['AQB']

/**
 * Gets the number query builder type for a query builder.
 */
type NQB<QB extends QueryBuilder<any, any>> = QB['NQB']

interface WhereMethod<QB extends QueryBuilder<any, any>> {
  // These must come first so that we get autocomplete.
  (id: ModelProps<QB>, op: Operator, value: Value): QB;
  (id: ModelProps<QB>, value: Value): QB;

  (id: Identifier, op: Operator, value: Value): QB;
  (id: Identifier, value: Value): QB;

  (cb: CallbackVoid<QB>): QB;
  (raw: Raw): QB;
  <QBA extends QueryBuilder<any>>(qb: QBA): QB;

  (obj: PartialPojo<ModelType<QB>>): QB;
  // We must allow any keys in the object. The previous type
  // is kind of useless, but maybe one day vscode and other
  // tools can autocomplete using it.
  (obj: object): QB;
}

interface FindById<QB extends QueryBuilder<any, any>> {
  (id: number): SQB<QB>
}

class QueryBuilder<M extends Model, R = M[]> extends Promise<R> {
  AQB: QueryBuilder<M, M[]>
  SQB: QueryBuilder<M, M>
  NQB: QueryBuilder<M, number>

  where: WhereMethod<this>;
  findById: FindById<this>;
}

interface StaticQueryMethod {
  <M extends Model>(this: ModelClass<M>): AQB<M['QB']>
}

interface QueryMethod {
  <M extends Model>(this: M): SQB<M['QB']>
}

interface ModelClass<M> {
  new (): M;
}

class Model {
  QB: QueryBuilder<this, this[]>

  static query: StaticQueryMethod;
  $query: QueryMethod
}

// Your types:

class AnimalQueryBuilder<M extends Model, R = M[]> extends QueryBuilder<M, R> {
  AQB: AnimalQueryBuilder<M, M[]>
  SQB: AnimalQueryBuilder<M, M>
  NQB: AnimalQueryBuilder<M, number>

  customMethod(): this {
    return notImplemented();
  }
}

class Person extends Model {
  firstName: string;
}

class Animal extends Model {
  QB: AnimalQueryBuilder<this, this[]>

  name: string;
  species: string;
}

function notImplemented<T>(): T {
  return {} as any;
}

async function basic() {
  const query = Person
    .query()
    .where('firstName', 'sami')
    .where(Person.query())
    .where({
      firstName: 'piss'
    })
    .where(qb => {
      qb.where('a', 1)
    })

  const persons = await query;
  console.log(persons[0].firstName);

  const person = await persons[0]
    .$query()
    .where(Person.query())
    .where(qb => {
      qb.where('a', 1)
    })

  console.log(person.firstName);
}

async function custom() {
  const query = Animal
    .query()
    .customMethod()
    .where(Animal.query().where({ name: 'a' }).customMethod())
    .where(qb => {
      qb.customMethod().where('name', 'Sami')
    })

  const animals = await query;
  console.log(animals[0].name)

  const animal = await animals[0]
    .$query()
    .customMethod()
    .where(qb => {
      qb.customMethod().where('a', 1).customMethod()
    })
    .where(Animal.query().customMethod())
    .customMethod()

  console.log(animal.name)
}

So the key is to add those three subtypes MQB, SQB and NQB for the custom query builder and the QB type for each model, and that's it! See Animal and AnimalQueryBuilder in the example above.

Good news is that it all seems to work. The bad news is that the types need to be completely rewritten.
So for anyone (most people) that didn't read my comment diarrhea, this is how you would create a custom query builder after the types have been rewritten:
class CustomQueryBuilder<M extends Model, R = M[]> extends QueryBuilder<M, R> {
  // Unfortunately these three types need to be hand-written for each custom query builder.
  AQB: CustomQueryBuilder<M, M[]>
  SQB: CustomQueryBuilder<M, M>
  NQB: CustomQueryBuilder<M, number>

  customMethod(): this {
    return 100;
  }
}

class BaseModel extends Model {
  QB: CustomQueryBuilder<this>
}

class Person extends BaseModel {
  firstName: string;
  lastName: string;
}

@falkenhawk What's with the eyes? :smile:

Those are my eyes at the moment. Wide-open in amazement

The new typings are being worked on in this branch.

Okay, the tricky parts of the typings are now ported to the new structure. There's still a lot of things to do to make them releasable (adding all methods the old typings had, adding tests, trying them out on real projects, etc). I won't be doing that anymore. I've already spent a week on this, when I was meant to be getting objection ready for 2.0. If you want the new typings for 2.0, help is needed.

@koskimas Will the new typings be merged into 2.0 and then incrementally added to or are you going to hold off on merging that branch until the typings are in a more complete state?

@willsoto The tests need to pass before it can be merged into 2.0

It's been over a year since I've had to do anything server-side, and I'm starting a new project, but this time I'm going to find a way to do without Objection, as much as I like it. I need a solution that prioritizes Typescript -- no builds without accurate types. Otherwise I'd offer to help with @koskimas's QueryBuilder support proposal.

@jtlapp Don't get me wrong, there's absolutely no obligation to help and there's already two lovely voluenteers that offered their help, but I fail to see the logic in your comment. You are saying you won't use objection because it doesn't prioritize typescript and use that as a reason to not help us prioritize typescript in objection?

I think prioritizing Typescript means committing to never releasing a feature unless it supports Typescript static type checking to the maximum degree possible in Typescript.
That means redesigning code to make static type checking possible in Typescript, not to the degree that existing Javascript permits, but to the degree that it is possible to do in Typescript. It starts with thinking, "What can Typescript do to help?" and working backwards from there.
I doubt there are many Javascript modules that adopt this principle. Usually when Typescript is valued enough to do this, the author will have written (or rewritten) the module in Typescript.
We may need a native Typescript equivalent of Objection. I betcha this would open up all sorts of syntax efficiencies not currently available, in addition to better type support. I wouldn't be hesitating then.

I just can't agree with that perspective, for a number of reasons. I have three main points that I'll list to keep it succinct:

those expectations are extremely high for basically any project in existence, and yet this is open source. When something isn't absolutely mission-critical with billions of dollars involved, it very rarely has that level of scrutiny.
typescript doesn't have enough capability to handle some of the typing structures needed that are well suited for ORMs (i don't agree with abandoning patterns in javascript that are a good fit, because the typing system can't handle it, especially when the types can be "good enough")
Personally, I'd much rather have a solid ORM which is good at run-time, and I can be confident about that aspect, rather than focusing on the types as much. Fully typed libraries are great and i'd love an ORM to exist that you describe, but I came from TypeORM; it has more detailed types, but it's also a giant mess with some rather large runtime bugs that are completely unnacceptable for me.

As a result of those three, that's why I'm putting effort into helping with Objections types primarily - I want to get them to a state where people can be confident about their correctness/robustness, as much as is possible with what typescript offers. My goal is to have all of the happy path covered correctly; anything not in the happy path I'm trying to get as much as is possible handled by types as well. Things like what functions can be called, at what time, on the query builder are not something that can be accounted for at this time, for example.

That's a good response @mordof. Thanks for the perspective. Here's a little more background.
I'm the one who redid the Objection typings to provide return types, but which apparently I did in a way that was incompatible with query builders.
I developed a server with those typings and found myself not needing the query builder after all. But I was still frustrated type lossiness and wondering all the way what would be possible were Objection written in Typescript with the intent of preserving type. (Unfortunately, I do not recall the issues I was facing at the time and so have no examples for you here.)
I may yet be back to help with Objection, but I'm got a few other avenues to explore first. I do know better than to touch TypeORM.

I'm the one who redid the Objection typings to provide return types,

Awesome :) didn't know that.

but which apparently I did in a way that was incompatible with query builders.

To be honest, I have yet to find a way that actually is correctly compatible with query builders. Every approach I've tried has had some problem or another, so the latest approach has some rigidity to it which is "kind of" matching the actual query builder. Especially because typescript has released some features only very recently that are bordering crucial to pull that off properly, I'd wager the complications being tackled now probably have less to do with your choices, and more to do with the lack of choices in general.

I developed a server with those typings and found myself not needing the query builder after all.

So you didn't need any .where() .findById() or any function basically from knex? I feel like I'm misunderstanding what you mean by that, because if that's actually true, then I'm having trouble understanding why you'd even bother using Objection, as that's basically all Objection is.

But I was still frustrated type lossiness and wondering all the way what would be possible were Objection written in Typescript with the intent of preserving type.

That's a fair point. Thinking back on my experiences with ORMs, I personally prefer query builders the most. That in itself is the problem for Objection types (bad typescript querybuilder capability). There are potentially other solid options for ORMs that don't use a query builder, but I stopped looking after objection, so I can't help you there.

I may yet be back to help with Objection, but I'm got a few other avenues to explore first.

Always good to explore your options :+1:. It's definitely crucial to use the right tool for the job. If Objection isn't it, that's perfectly fine... though it's always sad to see people go.

I do know better than to touch TypeORM.

:confetti_ball: :+1: :100:  I'm really happy to hear that. It's such a nightmare :laughing:
With all that said, I wish you happy hunting, and hope you find what you're looking for. Also if you do happen to find a query builder ORM that actually has reliable types around it, feel free to send me a link! I'd love to find an example to learn from.

I developed a server with those typings and found myself not needing the query builder after all.

So you didn't need any .where() .findById() or any function basically from knex? I feel like I'm misunderstanding what you mean by that, because if that's actually true, then I'm having trouble understanding why you'd even bother using Objection, as that's basically all Objection is.

Oops, sorry, I meant that I didn't need custom query builders, which is thing we couldn't type.

And I should mention that I had a lot of assistance from @mceachen, helping me to get unstuck and fixing my mistakes, because he had a better grasp of Typescript typings than I.

@jtlapp  ooh ok. That part has viable types now :slightly_smiling_face: it's in the new-typings branch, and is being worked on get those covering everything (at minimum) that was previously typed as well.
Once that process is done, I'm going to be reviewing absolutely all of the types and ensuring they're as complete/compatible as they can be. If there's viable changes to certain areas (e.g. some helpers to define properties on a model) for the actual js that can help improve/solidify the types, without taking away from the core style of objection, i'll be recommending/making PRs for those as well.

I do think it's possible to get close to what you're hoping Objection can be, however I acknowledge that will take time, and you may not be able to keep with Objection during that time. That's ok too.

I've got some experiments planned should either lead me to the right solution or else send me back here a bit smarter to help.

We can finally close this one. Fixed in v2.0 branch. Soon to be released

@koskimas thanks very much!


chore: derive serialize and deserialize for chain info

This change is

#2071
#2070  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ArniStarkware and the rest of your teammates on  Graphite


"skus" is required

Please use the Discussion board if you want to get some help. Please use issues to report bugs.

Description
I have successfully uploaded app on play store with (billing) permission and created package at in app product section. when call getProduct function, it gives me a error "skus is required". I don't understand why

Expected Behavior

Screenshots

Environment:

react-native-iap:
react-native:
Platforms (iOS, Android, emulator, simulator, device):

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Press '...'
Error '...' is shown

[Optional] Additional Context

Updated documentation: https://github.com/dooboolab/react-native-iap/pull/2143


test: Added a fix for flaky failure

fix for flaky behaviour for listv2_nested spec

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-k8s-25-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3283

Questions ?
Please refer to the Backport tool documentation


[Device Support Request] Update for lumi.plug quirk for total energy consumption

The Xiaomi smart plug (lumi.plug) is not appearing in the Home Assistant Energy integration under Individual Devices.
See https://github.com/home-assistant/core/issues/59032
According to @Adminiuga "The quirk for lumi plug in zha-device-handlers needs to get updated to provide summation attribute for energy consumed."
Device signature:
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4447, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=0, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0002",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x000a",
        "0x0010",
        "0x0b04"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "2": {
      "profile_id": 260,
      "device_type": "0x0009",
      "in_clusters": [
        "0x000c"
      ],
      "out_clusters": [
        "0x0004",
        "0x000c"
      ]
    },
    "3": {
      "profile_id": 260,
      "device_type": "0x0053",
      "in_clusters": [
        "0x000c"
      ],
      "out_clusters": [
        "0x000c"
      ]
    }
  },
  "manufacturer": "LUMI",
  "model": "lumi.plug",
  "class": "zhaquirks.xiaomi.aqara.plug.Plug"
}

Pairing log (hopefully I managed to capture all the relevant info):
2021-11-09 08:16:58 INFO (MainThread) [zigpy_deconz.zigbee.application] New device joined: 0xa5cd, 00:15:8d:00:01:b7:97:df
2021-11-09 08:16:58 INFO (MainThread) [zigpy.application] New device 0xa5cd (00:15:8d:00:01:b7:97:df) joined the network
2021-11-09 08:16:58 DEBUG (MainThread) [zigpy.device] [0xa5cd] Scheduling initialization
2021-11-09 08:16:58 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=False> from ep 0 to ep 0, cluster 19: b'\xa1\xcd\xa5\xdf\x97\xb7\x01\x00\x8d\x15\x00\x8e'
2021-11-09 08:16:58 DEBUG (MainThread) [zigpy.zdo] [0xa5cd:zdo] ZDO request ZDOCmd.Device_annce: [0xA5CD, 00:15:8d:00:01:b7:97:df, 142]
2021-11-09 08:16:58 DEBUG (MainThread) [zigpy.util] Tries remaining: 3
2021-11-09 08:16:58 INFO (MainThread) [zigpy.device] [0xa5cd] Requesting 'Node Descriptor'
2021-11-09 08:16:58 DEBUG (MainThread) [zigpy.util] Tries remaining: 2
2021-11-09 08:16:58 DEBUG (MainThread) [zigpy.device] [0xa5cd] Extending timeout for 0x30 request
2021-11-09 08:17:02 INFO (MainThread) [homeassistant.components.nmap_tracker] No MAC address found for <IP_ADDRESS>
2021-11-09 08:17:17 ERROR (SyncWorker_2) [homeassistant.components.influxdb] InfluxDB database is not accessible due to '401: {"code":"unauthorized","message":"Unauthorized"}'. Please check that the database, username and password are correct and that the specified user has the correct permissions set. Retrying in 60 seconds.
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.util] Tries remaining: 1
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.device] [0xa5cd] Extending timeout for 0x32 request
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=False> from ep 0 to ep 0, cluster 32770: b'2\x00\xcd\xa5\x01@\x8e_\x11\x7fd\x00\x00\x00d\x00\x00'
2021-11-09 08:17:26 INFO (MainThread) [zigpy.device] [0xa5cd] Got Node Descriptor: NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4447, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=0, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)
2021-11-09 08:17:26 INFO (MainThread) [zigpy.device] [0xa5cd] Discovering endpoints
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.util] Tries remaining: 3
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=False> from ep 0 to ep 0, cluster 32773: b'4\x00\xcd\xa5\x03\x01\x02\x03'
2021-11-09 08:17:26 INFO (MainThread) [zigpy.device] [0xa5cd] Discovered endpoints: [1, 2, 3]
2021-11-09 08:17:26 INFO (MainThread) [zigpy.device] [0xa5cd] Initializing endpoints [<Endpoint id=1 in=[] out=[] status=<Status.NEW: 0>>, <Endpoint id=2 in=[] out=[] status=<Status.NEW: 0>>, <Endpoint id=3 in=[] out=[] status=<Status.NEW: 0>>]
2021-11-09 08:17:26 INFO (MainThread) [zigpy.endpoint] [0xa5cd:1] Discovering endpoint information
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.util] Tries remaining: 3
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=False> from ep 0 to ep 0, cluster 32772: b'6\x00\xcd\xa5\x1e\x01\x04\x01Q\x00\x01\t\x00\x00\x04\x00\x03\x00\x06\x00\x10\x00\x05\x00\n\x00\x01\x00\x02\x00\x02\x19\x00\n\x00'
2021-11-09 08:17:26 INFO (MainThread) [zigpy.endpoint] [0xa5cd:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=81, device_version=1, input_clusters=[0, 4, 3, 6, 16, 5, 10, 1, 2], output_clusters=[25, 10])
2021-11-09 08:17:26 INFO (MainThread) [zigpy.endpoint] [0xa5cd:2] Discovering endpoint information
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.util] Tries remaining: 3
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=False> from ep 0 to ep 0, cluster 32772: b'8\x00\xcd\xa5\x0e\x02\x04\x01\t\x00\x01\x01\x0c\x00\x02\x0c\x00\x04\x00'
2021-11-09 08:17:26 INFO (MainThread) [zigpy.endpoint] [0xa5cd:2] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=2, profile=260, device_type=9, device_version=1, input_clusters=[12], output_clusters=[12, 4])
2021-11-09 08:17:26 INFO (MainThread) [zigpy.endpoint] [0xa5cd:3] Discovering endpoint information
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.util] Tries remaining: 3
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.application] Received frame on uninitialized device <Device model=None manuf=None nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=False> from ep 0 to ep 0, cluster 32772: b':\x00\xcd\xa5\x0c\x03\x04\x01S\x00\x01\x01\x0c\x00\x01\x0c\x00'
2021-11-09 08:17:26 INFO (MainThread) [zigpy.endpoint] [0xa5cd:3] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=3, profile=260, device_type=83, device_version=1, input_clusters=[12], output_clusters=[12])
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=60 command_id=Command.Read_Attributes_rsp>
2021-11-09 08:17:26 INFO (MainThread) [zigpy.device] [0xa5cd] Read model 'lumi.plug' and manufacturer 'LUMI' from <Endpoint id=1 in=[basic:0x0000, groups:0x0004, identify:0x0003, on_off:0x0006, binary_output:0x0010, scenes:0x0005, time:0x000A, power:0x0001, device_temperature:0x0002] out=[ota:0x0019, time:0x000A] status=<Status.ZDO_INIT: 1>>
2021-11-09 08:17:26 INFO (MainThread) [zigpy.device] [0xa5cd] Discovered basic device information for <Device model='lumi.plug' manuf='LUMI' nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=True>
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.application] Device is initialized <Device model='lumi.plug' manuf='LUMI' nwk=0xA5CD ieee=00:15:8d:00:01:b7:97:df is_initialized=True>
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.quirks.registry] Checking quirks for LUMI lumi.plug (00:15:8d:00:01:b7:97:df)
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.xiaomi.aqara.plug.Plug'>
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.quirks.registry] Found custom device replacement for 00:15:8d:00:01:b7:97:df: <class 'zhaquirks.xiaomi.aqara.plug.Plug'>
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.discovery] 'sensor' component -> 'ElectricalMeasurement' using ['electrical_measurement']
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.discovery] 'sensor' component -> 'ElectricalMeasurementRMSCurrent' using ['electrical_measurement']
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.discovery] 'sensor' component -> 'ElectricalMeasurementRMSVoltage' using ['electrical_measurement']
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.gateway] device - 0xA5CD:00:15:8d:00:01:b7:97:df entering async_device_initialized - is_new_join: True
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.gateway] device - 0xA5CD:00:15:8d:00:01:b7:97:df has joined the ZHA zigbee network
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xA5CD](lumi.plug): started configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:ZDO](lumi.plug): 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0006]: skipping channel configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0b04]: skipping channel configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0000]: skipping channel configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0019]: skipping channel configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:2:0x000c]: skipping channel configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:3:0x000c]: skipping channel configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0006]: 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0b04]: 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0000]: 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0019]: 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:2:0x000c]: 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:3:0x000c]: 'async_configure' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xA5CD](lumi.plug): completed configuration
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xA5CD](lumi.plug): stored in registry: ZhaDeviceEntry(name='LUMI lumi.plug', ieee='00:15:8d:00:01:b7:97:df', last_seen=1636409846.8312185)
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xA5CD](lumi.plug): started initialization
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:ZDO](lumi.plug): 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (00:15:8d:00:01:b7:97:df, 1, 0, 4, 'LUMI') params: FOREIGN KEY constraint failed
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0006]: 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0b04]: 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0000]: 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0019]: 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:2:0x000c]: 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:3:0x000c]: 'async_initialize' stage succeeded
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xA5CD](lumi.plug): power source: Mains
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xA5CD](lumi.plug): completed initialization
2021-11-09 08:17:26 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new sensor.zha entity: sensor.lumi_lumi_plug_df97b701_electrical_measurement
2021-11-09 08:17:26 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new sensor.zha entity: sensor.lumi_lumi_plug_df97b701_electrical_measurement_rms_current
2021-11-09 08:17:26 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new sensor.zha entity: sensor.lumi_lumi_plug_df97b701_electrical_measurement_rms_voltage
2021-11-09 08:17:26 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new sensor.zha entity: sensor.lumi_lumi_plug_df97b701_analog_input
2021-11-09 08:17:26 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new sensor.zha entity: sensor.lumi_lumi_plug_df97b701_analog_input_2
2021-11-09 08:17:26 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0006]: attempting to update onoff state - from cache: False
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (00:15:8d:00:01:b7:97:df, 1, 0, 5, 'lumi.plug') params: FOREIGN KEY constraint failed
2021-11-09 08:17:26 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=62 command_id=Command.Read_Attributes_rsp>
2021-11-09 08:17:26 INFO (MainThread) [homeassistant.helpers.entity_registry] Registered new switch.zha entity: switch.lumi_lumi_plug_df97b701_on_off
2021-11-09 08:17:31 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:1:0x000a] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=False disable_default_response=True> manufacturer=None tsn=124 command_id=Command.Read_Attributes>
2021-11-09 08:17:31 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:1:0x000a] ZCL request 0x0000: [[0]]
2021-11-09 08:17:33 INFO (MainThread) [homeassistant.components.nmap_tracker] No MAC address found for <IP_ADDRESS>
2021-11-09 08:17:44 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:2:0x000c] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=138 command_id=Command.Report_Attributes>
2021-11-09 08:17:44 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:2:0x000c] ZCL request 0x000a: [[Attribute(attrid=85, value=<TypeValue type=Single, value=48.619998931884766>)]]
2021-11-09 08:17:44 DEBUG (MainThread) [zigpy.zcl] [0xa5cd:2:0x000c] Attribute report received: present_value=48.619998931884766
2021-11-09 08:17:49 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xA5CD:1:0x0b04]: async_update
2021-11-09 08:17:49 DEBUG (MainThread) [zigpy.appdb] Error handling '_unsupported_attribute_added' event with (00:15:8d:00:01:b7:97:df, 1, 2820, 1293) params: FOREIGN KEY constraint failed
2021-11-09 08:17:49 DEBUG (MainThread) [zigpy.appdb] Error handling '_unsupported_attribute_added' event with (00:15:8d:00:01:b7:97:df, 1, 2820, 1288) params: FOREIGN KEY constraint failed
2021-11-09 08:17:49 DEBUG (MainThread) [zigpy.appdb] Error handling '_unsupported_attribute_added' event with (00:15:8d:00:01:b7:97:df, 1, 2820, 1290) params: FOREIGN KEY constraint failed
2021-11-09 08:17:49 DEBUG (MainThread) [zigpy.appdb] Error handling '_unsupported_attribute_added' event with (00:15:8d:00:01:b7:97:df, 1, 2820, 1285) params: FOREIGN KEY constraint failed
2021-11-09 08:17:49 DEBUG (MainThread) [zigpy.appdb] Error handling '_unsupported_attribute_added' event with (00:15:8d:00:01:b7:97:df, 1, 2820, 1287) params: FOREIGN KEY constraint failed

Any update on this?

Have updated and am confirming that this plug still doesn't work.

yes still not working

Please fix this. Energy consumption is a very important part of this device and we don't want to loose it in ZHA.
Please add!

Same issue here. Did you find a fix?

I did not, I've been slowly replacing this device because of this issue
On Wed, 4 Jan 2023, 07:58 cobch, @.***> wrote:

Same issue here. Did you find a fix?
—
Reply to this email directly, view it on GitHub
https://github.com/zigpy/zha-device-handlers/issues/1135#issuecomment-1370119283,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUMWJOGE4PJWG4CNG24356LWQRZGTANCNFSM5HT3LCHA
.
You are receiving this because you commented.Message ID:
@.***>

Alternativ is to switch to Z2m? I see... I have just received the SkyConnect but did not see any support yet on z2m. Maybe I should wait in that case since I want to switch from deconz to something more futur proof...

My hub doesn't allow me to use ZigBee2Mqtt so unfortunately that's not an
option for me
On Wed, 4 Jan 2023, 09:22 cobch, @.***> wrote:

Alternativ is to switch to Z2m? I see... I have just received the
SkyConnect but did not see any support yet on z2m. Maybe I should wait in
that case since I want to switch from deconz to something more futur
proof...
—
Reply to this email directly, view it on GitHub
https://github.com/zigpy/zha-device-handlers/issues/1135#issuecomment-1370190139,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUMWJOH4KUFXW2ROX6Q6W2LWQSC7RANCNFSM5HT3LCHA
.
You are receiving this because you commented.Message ID:
@.***>

Please post the diagnostic information from a lumi.plug that has been plugged in for some time with a load attached.

I have just received the SkyConnect but did not see any support yet on z2m.

It's experimental support but you just need to set the adapter type to "ezsp".

Attached is an image that shows the sensors I can see.

The "0.4" seems to be a power consumption of "0.4 W", right?
And is "130.7" the total energy consumption? (So does that value only ever increase?)
If so, we'd just need to put the values on a LocalDataCluster (energy and metering).
Also, what's the binary input sensor for the plug doing?

That value only ever increases, yes. I assume the binary sensor is the
power for the plug (on-off)
On Wed, 4 Jan 2023, 18:30 TheJulianJES, @.***> wrote:

The "0.4" seems to be a power consumption of "0.4 W", right?
And is "130.7" the total energy consumption? (So does that value only ever
increase?)
If so, we'd just need to put the values on a LocalDataCluster (energy and
metering).
Also, what's the binary input sensor for the plug doing?
—
Reply to this email directly, view it on GitHub
https://github.com/zigpy/zha-device-handlers/issues/1135#issuecomment-1370505134,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUMWJOD3T5THBMMJMKP5IS3WQUDI5ANCNFSM5HT3LCHA
.
You are receiving this because you commented.Message ID:
@.***>

Does the second AnalogInput automatically increase (when the attached device is powered on) or does it only update on HA restarts?

Both analog inputs only update when HomeAssistant restarts, and the binary
input is not tied into whether or not the switch is on (currently running a
dishwasher cycle and the binary input still says off)
On Wed, 4 Jan 2023, 19:39 TheJulianJES, @.***> wrote:

Does the second AnalogInput automatically increase (when the attached
device is powered on) or does it only update on HA restarts?
—
Reply to this email directly, view it on GitHub
https://github.com/zigpy/zha-device-handlers/issues/1135#issuecomment-1370538793,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUMWJOFKBKQGNZC3N2YUP5DWQULLHANCNFSM5HT3LCHA
.
You are receiving this because you commented.Message ID:
@.***>

Can you use the "reconfigure this device" option for the plug and see if one or both AnalogInputs then update without restarting?
(At least the first one might need a power change of like 10W)

No luck, device reconfiguration fails and the inputs don't update.

Download
Please try this custom quirk: TJJ_lumi_plug_test_v1.zip
Install Instructions
In your configuration.yaml, you might need to define the following if you don't have it already:
zha:
  custom_quirks_path: /config/zha_custom_quirks

This assumes you're running Home Assistant OS (points to /config).
Then, put the tjj_lumi_plug_v1 folder in that zha_custom_quirks folder, reboot HA, and then re-pair the plugs! (This is important)
In the end, the folder structure should look like this: /config/zha_custom_quirks/tjj_lumi_plug_v1
The last folder should contain two files: __init__.py and plug.py
More Info
(Make sure you re-paired the plug!) (It's possible that you even need to remove the plug from ZHA and then re-add it)
Let me know what works with this quirk and what doesn't (if values update and so on).
If the total power consumption (i. e. the second AnalogInputCluster) never updates, try uncommenting the commented lines in the plug.py file (marked withUNCOMMENT BELOW TO TEST 2nd PART OF POSSIBLE FIX):
Then, restart HA. A re-pairing shouldn't be necessary here.

Okay so enabling this
zha:
custom_quirks_path: /config/zha_custom_quirks
in my config causes my Zigbee network to crash.

Ah yeah, (remove it for now). I'll fix it soon-ish

Please try this:
TJJ_lumi_plug_test_v2.zip

Okay now the first analog input is updating but the second even with the
possible fix is still refusing to update.
(image showing the values of the first)
[image: image.png]
On Mon, 16 Jan 2023 at 06:38, TheJulianJES @.***> wrote:

Please try this:
TJJ_lumi_plug_test_v2.zip
https://github.com/zigpy/zha-device-handlers/files/10420799/TJJ_lumi_plug_test_v2.zip
—
Reply to this email directly, view it on GitHub
https://github.com/zigpy/zha-device-handlers/issues/1135#issuecomment-1383208789,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUMWJOFTSMRTTEHHXMC5HHLWSQYYVANCNFSM5HT3LCHA
.
You are receiving this because you commented.Message ID:
@.***>

Images apparently aren't sent correctly via email. (Can you send it again using GitHub directly?)
And just to confirm, you tried removing the plug from HA and re-pairing it while the "v2 quirk" is installed?
Also, what coordinator do you have (and what firmware)?

updated quirk, restarted HA, removed device, re-paired.
without 2nd part enabled, minimal load (xiaomi bedside lamp powered, but lamp off):

without 2nd part enabled, higher load (xiaomi bedside lamp on):

without 2nd part enabled, higher load after 5 minutes (xiaomi bedside lamp on) - no change on second analogue input

WITH 2nd part enabled, higher load (xiaomi bedside lamp on) enabled:

WITH 2nd part enabled, higher load (xiaomi bedside lamp on) enabled, after one hour:

Please try this: TJJ_lumi_plug_test_v3.zip
You'll need to re-pair the plug again though. A new sensor for the total consumption should show up. (The AnalogInput sensors can be ignored then). Let me know if the total consumption sensor updates properly.
I've also increased the logging to warning of Xiaomi attribute reports for that plug, so you'll (hopefully) see some logs containing: DEBUG TJJ QUIRK. These are expected (please send them here).

Will be another 12 hours before I can test. But will do.

Test it without uncommenting that part first.

updated quirk, restarted HA, removed device, re-paired.
without 2nd part enabled, minimal load (xiaomi bedside lamp powered, but lamp off):

without 2nd part enabled, maxload (xiaomi bedside lamp powered, and lamp on full brightness):

without 2nd part enabled, maxload (xiaomi bedside lamp powered, and lamp on full brightness) - 13 minutes later - summation delivered has increased.

debug:
2023-01-17 14:56:04.678 WARNING (MainThread) [lumi2] 00:15:8d:00:02:8b:71:cf - (DEBUG TJJ QUIRK) Attribute report. attribute_id: [65281] value: [{'0xff01-100': <Bool.false: 0>, 'temperature': 25, 'power': 0.0, 'consumption': 11.694486618041992, 'voltage': 2380, 'X-attrib-5': 51, '0xff01-154': 16, '0xff01-8': 4886, '0xff01-7': 0, '0xff01-9': 512}]
2023-01-17 15:01:47.622 WARNING (MainThread) [lumi2] 00:15:8d:00:02:8b:71:cf - (DEBUG TJJ QUIRK) Attribute report. attribute_id: [65281] value: [{'0xff01-100': <Bool.true: 1>, 'temperature': 39, 'power': 5.296999931335449, 'consumption': 11.694499969482422, 'voltage': 2380, 'X-attrib-5': 51, '0xff01-154': 0, '0xff01-8': 4886, '0xff01-7': 0, '0xff01-9': 512}]
2023-01-17 15:06:52.621 WARNING (MainThread) [lumi2] 00:15:8d:00:02:8b:71:cf - (DEBUG TJJ QUIRK) Attribute report. attribute_id: [65281] value: [{'0xff01-100': <Bool.true: 1>, 'temperature': 39, 'power': 13.088000297546387, 'consumption': 11.69559097290039, 'voltage': 2380, 'X-attrib-5': 51, '0xff01-154': 0, '0xff01-8': 4886, '0xff01-7': 0, '0xff01-9': 512}]
2023-01-17 15:13:54.615 WARNING (MainThread) [lumi2] 00:15:8d:00:02:8b:71:cf - (DEBUG TJJ QUIRK) Attribute report. attribute_id: [65281] value: [{'0xff01-100': <Bool.true: 1>, 'temperature': 39, 'power': 13.088000297546387, 'consumption': 11.697200775146484, 'voltage': 2380, 'X-attrib-5': 51, '0xff01-154': 0, '0xff01-8': 4886, '0xff01-7': 0, '0xff01-9': 512}]

So "active power", "summation delivered", and "voltage" are updating correctly now (without restarting HA)?
(Ignore power factor and AnalogInput sensors)

yes - active power, summation delivered, and voltage appear to be correctly updating (Note that I restarted HA as part of redoing the quirk)

(summation is increasing, but the graph scale hides it)


[PG]: Add postgres 9.6

From @tamalsaha on May 24, 2017 2:55
Postgres 9.6 supports synchronous replication
Copied from original issue: kubedb/operator#37

https://github.com/kubedb/cli/releases/tag/0.8.0-beta.2


Fixes #385

Fixes #385.
Description of the changes:
-Changed data name="0" value from "0th" to "least significant"
-Changed data name="63" value from"63rd" to "most significant"
How changes were validated:

-Validated manually with Narrator ensuring that Narrator read "least significant bit..." when 0th bit was selected and "most significant bit..." when 63rd bit was selected.

@brulecap - Are you still planning on updating this PR, or should I close it out so that someone else can give it a try?  Thanks again.

@HowardWolosky, I'm good with closing this PR. I will continue to look at it and look forward to seeing how it is resolved. It's been a good learning experience for me. Thank you.


[WIP] libp2p extra logging on internode communication #2699

Proposed changes
To match changes introduced in open-acn PR
should be merged simultaneously otherwise this test will fail
Fixes
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce to agents-aea?
Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply.

[ ] I have read the CONTRIBUTING doc
[ ] I am making a pull request against the develop branch (left side). Also you should start your branch off our develop.
[ ] Lint and unit tests pass locally with my changes and CI passes too
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked that code coverage does not decrease.
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

Codecov Report

Merging #218 (ba16b84) into fix/update_cert_requests (4fa15b6) will not change coverage.
The diff coverage is n/a.

@@                    Coverage Diff                    @@
##           fix/update_cert_requests     #218   +/-   ##
=========================================================
  Coverage                     94.65%   94.65%
=========================================================
  Files                           311      311
  Lines                         24993    24993
=========================================================
  Hits                          23658    23658
  Misses                         1335     1335

Flag
Coverage Δ

unittests
94.65% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4fa15b6...ba16b84. Read the comment docs.

Lgtm


feat(provider): add TransactionsProvider and WithdrawalsProvider

Create TranasctionsProvider and WithdrawalsProvider. Refactor block id related methods to BlockIdProvider

Codecov Report

Merging #1431 (481f30f) into main (7c9b212) will decrease coverage by 57.73%.
The diff coverage is 6.04%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main    #1431       +/-   ##
===========================================
- Coverage   76.54%   18.82%   -57.73%
===========================================
  Files         356      358        +2
  Lines       40834    40910       +76
===========================================
- Hits        31256     7700    -23556
- Misses       9578    33210    +23632

Flag
Coverage Δ

integration-tests
18.82% <6.04%> (-3.66%)
:arrow_down:

unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

crates/primitives/src/chain/info.rs
0.00% <0.00%> (ø)

crates/rpc/rpc/src/eth/api/mod.rs
21.33% <0.00%> (-53.34%)
:arrow_down:

crates/storage/provider/src/lib.rs
0.00% <ø> (-100.00%)
:arrow_down:

crates/storage/provider/src/providers/mod.rs
0.00% <0.00%> (-31.94%)
:arrow_down:

crates/storage/provider/src/traits/block.rs
100.00% <ø> (+50.00%)
:arrow_up:

crates/storage/provider/src/traits/transactions.rs
0.00% <0.00%> (ø)

crates/storage/provider/src/traits/block_id.rs
2.94% <2.94%> (ø)

crates/storage/provider/src/test_utils/noop.rs
6.89% <17.64%> (-36.86%)
:arrow_down:

crates/storage/provider/src/test_utils/mock.rs
14.00% <18.51%> (-37.57%)
:arrow_down:

bin/reth/src/lib.rs
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 252 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Return node information in supported fields.

Motivation
We want to build a response from falco in which we get the node information (VMs). We will use these VMs info in our rule exceptions
Feature
Falco should also have supported fields of node information.
Alternatives
Additional context

Hi @ajinkya1986, it would be helpful if you could provide explicit examples of information you need and that is not yet supported.

Hi,
In the supported fields as mentioned in the below documents we can get info of namespace from k8.ns.name or image name from container.image. Similarly I want info of the node name or node attributes.
https://falco.org/docs/rules/supported-fields/

Does the Falco -p work for you? It allows you to append arbitrary formatted strings to every alert output. In that way, you can add metadata info to your alert depending on the machine you are running Falco into.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Light & dark theme favicon option

Hi @McShelby,
One of my customers requested light & dark theme favicons yesterday, which was easy enough to implement. Would you be interested in a PR for this feature? I think others would like this option too. ?
My implementation:

Duplicated the existing favicon.html partial
Added a new condition at the beginning checking for the existence of /static/images/favicon-light.svg OR /static/images/favicon-dark.svg and made the existing conditions all chain off this one so that no other favicon conditions are evaluated if one or both of these files exist. In testing, a favicon without a media query overrode the media query version.

Added a condition within the new condition for to add favicon-light.svg if it exists with the appropriate media query
Same for the dark mode

As indicated, I only implemented this for SVG, but I could duplicate this for other types too in the PR if preferred. ?
Note: Media queries aren't supported for IE per https://caniuse.com/css-media-interaction, and I know that this project still supports it from recent mentions, but as long as it's noted in the docs (and partial?) that this feature isn't supported for edge case browsers & browser versions, I think it should be okay. Restating, this wouldn't break the existing logic- it adds it as a new most preferred option, so anyone with conflicting requirements could continue to use one of the existing favicon options or override the partial.
Interested?

@tlindsay42 Would that also work for "normal" images, i.e. could we have different images in dark mode versa light mode? That would be super handy!

Yep! Here's what the HTML looks like (with the asset cache busting feature enabled):
<link href="./images/favicon-light.svg?1685545177" rel="icon" type="image/svg+xml" media="(prefers-color-scheme: light)">
<link href="./images/favicon-dark.svg?1685545177" rel="icon" type="image/svg+xml" media="(prefers-color-scheme: dark)">

Just to make sure of the implications/limitations of this before implementing:

Your solution solely changes the favicon according the the OS's color scheme. No other images (neither referenced in markdown nor the themes logo) will change.
Also, if switching the theme with the variant selector will not cause the favicon to change.

To my belief this behavior is feasible as the favicon blends into the OS chrome and does not relate to the selected theme.
The only thing I don't like about that is, how to explain this complexity to the user. But as you've already mentioned: it's optional.
What's unclear to me is, how images are assigned to the perfers-color-scheme property if only a light or dark image is available but not both.

Your solution solely changes the favicon according the the selected OS's color scheme. No other images (neither referenced in markdown nor the themes logo) will change.

Correct, the feature will only change the favicon according to the OS' selected color scheme. No other images will change. Of note, Firefox and Edge will respect browser-level color scheme overrides, so if you set dark mode in the browser, but use light mode in the OS, you'll get a dark mode favicon. Chrome currently only respects the OS-level color scheme setting.

Also, switching the theme with the variant selector will not cause the favicon to change.

Correct, because the site's theme is independent of the OS/browser mode preference.

The only thing I don't like about that is, how to explain this complexity to the user.

I'll draft something up in a bit and we can negotiate it. No rush on this by any means.

What's unclear to me is, how images are assigned to the perfers-color-scheme property if only a light or dark image is available but not both.

Haven't tested this yet, but will in a bit. My expectation is that no favicon will be served if there's no match, such as if the developer forgets one of the files or names it incorrectly. Should be a similar experience if they did the same with any of the existing favicon options. I figured the more forgiving option was the better choice here.

Sounds all okay to me. Just make a PR and let us fix potential flaws there (if any)

Also, just re-read your previous question about "normal" images and realized I misunderstood what you were asking earlier. I've got a solution for that challenge too, but I'll have to think about how to adapt it for hugo.

Interesting testing results (more details on browser support)
Chrome - Only supports OS setting and switches its UI accordingly (okay)
Edge - Supports OS setting and manual setting in preferences and switches its UI accordingly (okay)
Firefox - Supports OS setting (switches UI) and manual setting in preferences (does not switch UI) (not so okayish)
This will cause Firefox to display the wrong icon if OS setting and manual setting differ. This can be observed with any GitHub page (like this one)
I can live with this as prominent pages like GitHub have the same issue.

Also, just re-read your previous question about "normal" images and realized I misunderstood what you were asking earlier. I've got a solution for that challenge too, but I'll have to think about how to adapt it for hugo.

This is more complicated as the render-image must be touched and should be handled in another issue.

...This should be handled in another issue.

100% agree and don't have the bandwidth for tackling this one right now. This issue is just for the light/dark theme favicon.

I am wondering why Fierefox and Chrome leave the UI unchanged when manually setting the option. No other app behaves like this. Also, there seems to be no technical limitation to switch this during runtime, as the OS setting is applied immediately without a restart of both browsers

Same. My guess is justifying investment & prioritization for features like this is tough when there's all sorts of things to address in the constantly changing ecosystem.

I'ld bet that Safari implements a forth variant.

lol agreed. I'll see if I can track down someone to test it today.

Tested the no match for mode scenario with both light & dark, and found that Chrome & Edge don't serve a favicon when there's no link with a matching media query, but Firefox will default to the entry even if the media query doesn't match.

Thanks for the submission. I've modified the code and also added lockup for the alternative logo, too. I hope it still works for your site.


Verbose not working with the Epochs.drop_bad method

Describe the bug
The verbose argument in not working in the drop_bad() method.
Steps to reproduce
import os
import mne

sample_data_folder = mne.datasets.sample.data_path(path='/db/psxjb6/mne_data')
sample_data_raw_file = os.path.join(sample_data_folder, 'MEG', 'sample',
                                    'sample_audvis_raw.fif')
raw = mne.io.read_raw_fif(sample_data_raw_file, verbose=False).crop(tmax=60)
events = mne.find_events(raw, stim_channel='STI 014')
epochs = mne.Epochs(raw, events, tmin=-0.3, tmax=0.7)

epochs.verbose = False

epochs.drop_bad(verbose=True)

Expected results
The verbose argument set to True overwrites the Epochs.verbose attribute and prints the number of bad epochs dropped.
86 events found
Event IDs: [ 1  2  3  4  5 32]
Not setting metadata
Not setting metadata
86 matching events found
Applying baseline correction (mode: mean)
Created an SSP operator (subspace dimension = 3)
3 projection items activated
Loading data for 86 events and 601 original time points ...
1 bad epochs dropped

Actual results
The number of bad epochs dropped is not printed.
86 events found
Event IDs: [ 1  2  3  4  5 32]
Not setting metadata
Not setting metadata
86 matching events found
Applying baseline correction (mode: mean)
Created an SSP operator (subspace dimension = 3)
3 projection items activated

Additional information
It seems that in the source code of drop_bad() the argument verbose which defaults to None is not used.

I confirm.  @HanBnrd are you up for making a PR to fix this?

Yes, I'll have a look at what needs to be modified to fix this.

It seems that this issue is also affecting other methods, such as Raw.load_data(). The verbose argument is not taken into account with the following code:
import os
import mne

sample_data_folder = mne.datasets.sample.data_path()
sample_data_raw_file = os.path.join(sample_data_folder, 'MEG', 'sample',
                                    'sample_audvis_raw.fif')
raw = mne.io.read_raw_fif(sample_data_raw_file, verbose=False).crop(tmax=60)

raw.load_data(verbose=True)

While this code prints info:
import os
import mne

sample_data_folder = mne.datasets.sample.data_path()
sample_data_raw_file = os.path.join(sample_data_folder, 'MEG', 'sample',
                                    'sample_audvis_raw.fif')
raw = mne.io.read_raw_fif(sample_data_raw_file, verbose=False).crop(tmax=60)

raw.verbose = True

raw.load_data()

Reading 0 ... 36037  =      0.000 ...    60.000 secs...

Also this following code doesn't print info:
import os
import mne

sample_data_folder = mne.datasets.sample.data_path()
sample_data_raw_file = os.path.join(sample_data_folder, 'MEG', 'sample',
                                    'sample_audvis_raw.fif')
raw = mne.io.read_raw_fif(sample_data_raw_file, verbose=False).crop(tmax=60)

mne.set_log_level(verbose=True)

raw.load_data()

Is the mne.set_log_level() function supposed to work in this case?

This issue seems to be related to the @verbose decorator not working in some cases (maybe working on functions or methods calling functions but not on proper methods?)...
An easy quick fix would be to explicitly use the verbose arguments in the methods instead of relying on @verbose but it is probably not a good long term solution to solve the issue on all the methods affected.

Also this following code doesn't print info:

That one at least shouldn't based on how the code is designed. The precedence/order is meant to be:

verbose arg is used if not None
verbose attribute of a class is used if not None
global verbose level is used

And in that last example, the raw gets initialized with verbose=False, so raw.load_data() should always be in non-verbose mode regardless of set_log_level.

(I can take a look at fixing the verbose decorator if it would help, since it does seem like the first/top-comment example is problematic)

(I can take a look at fixing the verbose decorator if it would help, since it does seem like the first/top-comment example is problematic)

Thanks @larsoner, that would be nice if you have time as I'm not very familiar with it and it appears to be used as a decorator for a lot of functions/methods in MNE. Please let me know if I can help.


docs(cta): update docs

What I did

Updated the docs for rh-cta element based on the specs mentioned in https://github.com/RedHat-UX/red-hat-design-system/issues/905

Testing Instructions

Review the updated docs for rh-cta(preview) and check if they match the design spec and the content

Notes to Reviewers

@bennypowers @coreyvickery  m not sure how descriptive we need to be with css props. there are so many css vars based on different variants and states. shall i include everything ? (reposting here from the gchat channel)

@diwanshi Great first pass. cc @bennypowers
Global

Change Call to Action to Call to action
Ensure there is 5.0rem (80px) of padding in between content and the Related elements or patterns and Feedback sections
Ensure the padding in between image containers is 2.0rem (32px) (Example: On the Style page under the Light and dark themes h3)
Ensure the padding in between an image container and a table is 2.0rem (32px) (Example: On the Style page under the Light and dark themes h3)
Ensure the padding in between an h2 and h3 is 2.0rem (32px) (Example: On the Guidelines page under the Writing content h2)

Guidelines page

Under the Call to action text labels h3, under the bullets, there is an extra link icon
Under the Too many options h3, the link does not go anywhere, please add the link from the Google doc

@coreyvickery

i don't have full access to content doc, can you provide me with the link for choice of paralysis text under Too many options(h3)?
all the paddings are managed currently by example scss file and I see a conflict in the example class

similarly for all the table paddings we'll need to update the styles, i see the same issue on other component docs as well
do you want to create another issue for these padding fixes or shall i tackle them in this same PR?

@coreyvickery apart from the padding changes i've fixed all the changes.

@coreyvickery all the changes have been made including repo status table spacing corrections.


LEFT JOIN on column with NULL value results in a segmentation fault

Consider the following statements:
CREATE TABLE t0(c0 INT);
CREATE TABLE t1(c0 INT);
INSERT INTO t0(c0) VALUES (0);
INSERT INTO t1(c0) VALUES (NULL);
SELECT * FROM t1 LEFT JOIN t0 ON t0.c0=t1.c0; -- Segmentation fault

Unexpectedly, the SELECT results in a segmentation fault:
build/release$ ./duckdb_cli
SQLite version DuckDB 340d867b
Enter ".help" for usage hints.
Connected to a transient in-memory database.

Fixed this in c40e4ca4b08c65213d74f6f4349d46cf5c25f430. The issue was that the found_match array that keeps track of whether or not a match for the tuple had been found was initialized after we filtered NULL values. Since in this example the probe side only contained NULL values, this array was never initialized, hence resulting in a segmentation fault when trying to access it.


java.lang.IllegalStateException

java.lang.IllegalStateException: Observer com.beloo.widget.chipslayoutmanager.layouter.MeasureSupporter@6c0f5aa is already registered.
When I call setAdapter the second time for my RecyclerView which has ChipsLayoutManager, it will give me this error.

I think you would have to remove the first line in function onAdapterChanged(), because when setAdapter of the RecyclerView called, the data observer is already registered.
Didn't figure out why you explicitly registered it again, so if registering it is necessary in some circumstances, I think you may have to check if the data observer is registered or not before that.

Yes, this issue goes into more deeper problem, coz in case changing adapters - layout manager will listen for both of them with current implementation, which is really incorrect. Thanks again for nice feedback

fixed in v0.3.5. Covered with functional test

👍  👍 👍

Yeah, it's perfectly done. Had to clean the project and rebuild it after changing to the newer version. Thanks for you efforts.

np


Add my project, please: Forta

twitter: @FortaProtocol
github: https://github.com/forta-protocol/forta-agent-sdk

thanks!

Added, thanks! :)


[Building k8s extensions for database SingleInstance] -u option is throwing an unknown option error

Hi all,
building the k8s extensions for the single database image, I found an issue.
The unknown option error was thrown by the
/usr/bin/python -u
in
https://github.com/oracle/docker-images/blob/main/OracleDatabase/SingleInstance/extensions/k8s/lock.py#L1
By removing the -u, I was able to fix the issue.
Thanks

@mfabbri For which database version have you tried building k8s extension ??

Hi @abhisbyk: 19.3 Enterprise Edition

This happened to me when I cloned the docker-images git repository on a Windows machine and the line endings on some files, including lock.py, were changed to CRLF. Executing this before cloning fixed the problem:
git config --global core.autocrlf false

Thank you @zsrv ! This tip fixed the issue!


Telemetry Exporter

As a maintainer of NGF
I want an exporter library to enable me to send data to a centralized telemetry collector
So that I can aggregate and visualize telemetry data to make better product decisions based on how users are using the products.
Acceptance

Data sent to the exporter library is able to send data to our centralized collector.
A set of common data points for NGF/NIC telemetry is identified within the exporter library.
The README is updated to include how to use the Telemetry Exporter as a developer.
The library interfaces are reviewed and approved by both NGF and NIC teams and @f5yacobucci

Testing Notes

We need to add an automated test to validate that the format of what is sent by the exporter matches the Open Telemetry format.

Blocked by #1374

The last part of it - docs - is being worked here https://github.com/nginxinc/telemetry-exporter/issues/5
Closing this issue


update pyproject.toml to point to the new organization

The pyproject.toml isn't up to date for pointing to the correct repository location and is still referencing "https://github.com/CoreySpohn/yieldplotlib"

Fixed in #22


[Feature] Improve SEO by Adding Meta Description Tag

Problem
The current HTML head section lacks a meta description tag, which could  impact the search engine ranking negatively and make discovering the page difficult. A meta description provides search engines with a concise summary of the page's content, which is used in search result snippets. Adding this tag would improve the page's visibility and provide a better search experience.
Description
This feature involves adding a <meta name="description"> tag in the head section of the HTML document, providing a brief summary of the page content.
Implementation

[x] would be interested in implementing this feature.

We'd need to decide on what this would say before this could move forward. Suggestion?

@possumbilities Explore CC Search Portal and join a global community that supports creativity and sharing of knowledge.Discover openly licensed images, music and more. What do you think?

Let me look for another example

Discover the Creative Commons Search Portal, a platform for creators to find and use openly licensed images, music, and other media. Empowering legal sharing and innovation through Creative Commons licenses.
@possumbilities How about this?

The Creative Commons Search Portal helps creators find and use openly licensed images, music, and more. It aggregates content that can be legally shared and reused under Creative Commons licenses
@possumbilities Or this?

@Silvia-Wachira I think the second one sounds better than the first, but maybe include a little more information about the educational or teaching aspect of creative commons?


make cif panel writable

closes #343

@newville do you agree making CIF panel writable?

@maurov I don't disagree, but it is slightly complicated.  Right now, CIF files are parsed, with various parts put into the sqlite database.  So on display, there is a CIF object, and what is shown is the text of the CIF file generated from that object, and the calculations use the CIF object they don't currently re-parse that text as displayed.
So it's a bit more work than just changing to "make text box editable".  I think it's a fine idea, but maybe with a button to enable editing (which would then either replace that CIF entry or add a new one in the database for future use).

@newville thanks for clarifying this. OK, then I propose to close this pull request and put aside the idea of editing CIF files at the moment. It is not top priority, in my opinion.


add presentation slides

should include updates to the build pipeline to produce an artifact for viewing slides (i.e., html5 document) that includes same figures/tables in manuscript rendered via m30ml model

closed as per #236


Please correct some misleading information in this repo

The binaries provided here are not an official Redis port to Windows, and should not be presented as such.
Also, Redis 7.0 was not released yet so at best this port is based on a release candidate.

The binaries provided here are not an official Redis port to Windows, and should not be presented as such. Also, Redis 7.0 was not released yet so at best this port is based on a release candidate.

ok,thanks,i will correct it on 13 March.

I've spent a lot of time working on the windows edition and if people don't like it I'll close the project in the future


What's the significance of VM?

This page is titled 'What is managed identities for Azure resources?' yet it makes reference to Azure virtual machines (VM) often, as if it has some sort of significance versus other Azure resources. If it does or does not, it should mention so.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 72861cc1-7081-cf6e-b7f9-e700a16faa9a
Version Independent ID: c870872d-0559-6b77-280f-f478e8c84776
Content: Managed identities for Azure resources
Content Source: articles/active-directory/managed-identities-azure-resources/overview.md
Service: active-directory
Sub-service: msi
GitHub Login: @MarkusVi
Microsoft Alias: markvi

@marckassay
Thanks for your feedback! We will investigate and update as appropriate.

#reassign:barclayn

@marckassay thank you for your feedback. We have recently made updates to the overview that we hope help address the issue you brought up. If you feel that this is still a problem please let us know. If you have another suggestion for how we may improve our documentation, please don’t hesitate to reach out again. #please-close