Nested relations using createMany

As per my understanding  await prisma.accoutns.createMany() works only on a single entity and not on sub-entities. hence i tried to use create along with createMany as mentioned in this ticket.
https://github.com/prisma/prisma/issues/4998
but currently it is not working at sub levels as well which is an issue for example.

What i am expecting is i should be able to efficiently create multiple entities with children entities at N level like we could currently do with .create({})  but it is highly inefficient.

@yousufhasan  As I understand the doc says when using createMany, you cannot nest relation queries, so given your example, even if you called create in the top parent query, nesting lineItems in subAccounts is not supported, once you use createMany, no other query can be nested into it.

@jalik Shouldn't it be supported? The problem we are facing currently is that create is highly inefficient when it comes to creating large nested objects. is there any other way to efficiently save nested objects like in other orm tools like TypeORM?

@yousufhasan I am not from the Prisma team, but I guess since it's a preview feature it's still incomplete, but it may be supported later.

Hey, I just wanted to add my support for this. It would make a major difference in my project.

This feature would be amazing!

This would be ground-breaking for my use case, would save tons of redundant code.

As nested createMany is not implemented, how should one efficiently load big amounts of relational data (e.g. Users & Posts)?
The logical approach would be to run a createMany on the Users first, and then a createMany on the Posts.
But in order to connect them properly, the first createMany would need to return the inserted Users (or at least the IDs), which it unfortunately does not...
What are your workarounds on this?

As nested createMany is not implemented, how should one efficiently load big amounts of relational data (e.g. Users & Posts)?
The logical approach would be to run a createMany on the Users first, and then a createMany on the Posts.
But in order to connect them properly, the first createMany would need to return the inserted Users (or at least the IDs), which it unfortunately does not...
What are your workarounds on this?

Many "create" in a for of / foreach (depending on how you want to await the promises) loop for now
And as per @yoni2356 comment

Furthermore, correct me if I am wrong please, this is the most logical way I can think of, hence necessary way for creating such deeply nested entities - and returning them without selecting them after creation.

Agree on the most logical way but it's not the only way. Nested writes are mainly needed for expressing db transactions in a fancy and fast way, but no one stops you from using an interactive transaction and put the many creates inside a loop as I've expressed above

+1, this would be great!

I appreciate what the Prisma team is doing, but to be honest going the Sequelize way of passing in a full body json with keys identifying the relationship, is the most logical and easiest way to do nested writes. I have no idea why the Prisma team decided to go this way, as it leads to unnecessary transformation code logic(map, for loops)

Is there a feature request for what you are describing @NathBabs? Maybe we are just not aware.

@NathBabs is that a good description of what you expect form prisma ?
https://github.com/prisma/prisma/issues/11224
I feel it could be improved that way.

@jalik @janpio yes exactly, that issue captures what I mean. The adding of the connect, create, createMany is unnecessary. Anytime I receive a JSON structure on the backend I always have to transform it because of Prisma, I hardly ever did so with Sequelize.
JSON already has its own specifications catering to nesting and arrays. If it's an array then it's automatically a bulk insert. So no need to add on top of that. I
This is how Sequelize handles nested writes, it's so simple.
https://sequelize.org/master/manual/creating-with-associations.html

This would be a great feature! Example of how I would see it work: add the desired relation and do an opertion.
       createMultipleCards:(_parent,_args,ctx)=>{

            const markedCards = _args.cards.map(card=>{
                return {
                    ...card,
                    leadTimes:{
                        create:{
                            state: card.card_state
                        }
                    }
                }
            });

            return ctx.prisma.card.createMany({
                data:markedCards,
                skipDuplicates: true
            })
        }

+1!

https://github.com/merthanmerter/prisma-nested-createMany-hack

https://github.com/merthanmerter/prisma-nested-createMany-hack

the link is broken

https://github.com/merthanmerter/prisma-nested-createMany-hack

the link is broken

sorry it wasnt public

https://github.com/merthanmerter/prisma-nested-createMany-hack

This works but you get no types. Not sure they intended for this to work.

I didn't bother finding any other way to migrate my messy json database to sql. It is not recommended but can be useful in dev handled environments.

https://github.com/merthanmerter/prisma-nested-createMany-hack

Thanks. But this doesn't solve the problem, you are just calling create multiple times.

All feature requests that are still open are considered by the team. But as you can see, there are many of those. Hence it might take some time to really get to this one. On the other hand, it has a lot of upvotes and comments - so this is definitely higher on that list than others. More comments with uses cases and information is always welcome and will help us to decide if an issue is worth going deeper into when we look for new things to work on.

All feature requests that are still open are considered by the team. But as you can see, there are many of those. Hence it might take some time to really get to this one. On the other hand, it has a lot of upvotes and comments - so this is definitely higher on that list than others. More comments with uses cases and information is always welcome and will help us to decide if an issue is worth going deeper into when we look for new things to work on.

Here is my current flow that is limited by not having nested createMany.
Take the following database structure:

The use case is the following:
The diagram above represents some kind of template. There is a feature that allows the user to clone that template for whatever reason.
For each product, there would be around 5 processes, each process would have around 200 items, each item would have 1 criteria, 1 instruction, both criteria and instruction have 1 or more images.
If we do some math it would amount to this:
1 product
5 processes
1.000 items (5 processes X 200 items)
1.000 criteria (total items X 1)
1.000 instructions (total items X 1)
4.000 images ((total criteria X 2) + (total instructions X 2)) // If we assume each criteria and instruction will have 2 images
In total this would be around 7.000 entities that need to be created at once.
Plus criteria <=> images and instruction <=>= images are many to many relations so that would add even more creations to the total sum.
We could utilize the create on an entity like so:
prisma.process.createMany({
    data: {
        name: 'test',
        items: {
           create: [ /* array of items to create*/ ]
        }
    }
})

But that ends up doing INSERT for each entity and the end result is incredibly slow. 3.5 minutes as of the last testing.
So we ended up precomputing the IDs and then connecting them all together. Ideally this would be in a transaction but I haven't gotten to that yet.
public async clone(input: CloneProductInput): Promise<CloneProductPayload> {
    const existingProduct = await orm.product.findUnique({
        select: PRODUCT_DEFAULT_SELECT(),
        where: {
            id: input.id,
        },
    })

    if (!existingProduct) {
        throw new Error(`Attempted to clone non-existent product by ID: ${input.id}`)
    }

    /**
     *  Precomputing IDs
    **/

    const precomputedProduct = {
        ...existingProduct,
        newId: UUID(),
    }

    const precomputedProcesses = existingProduct.processes.map((process) => {
        return {
            ...process,
            newId: UUID(),
        }
    })

    const precomputedAssemblyProcesses = existingProduct.assemblyProcesses.map((assemblyProcess) => {
        return {
            ...assemblyProcess,
            newId: UUID(),
        }
    })

    const precomputedItems = existingProduct.processes.flatMap((process) => {
        return process.items.map((item) => {
            return {
                ...item,
                newId: UUID(),
            }
        })
    })

    const precomputedCriteria = precomputedItems.flatMap((precomputedItem) => {
        if (!precomputedItem.criteria) {
            throw new Error('No criteria found for item while cloning product')
        }

        return {
            ...precomputedItem.criteria,
            itemId: precomputedItem.newId,
            newId: UUID(),
        }
    })

    const precomputedInstructions = precomputedItems.flatMap((precomputedItem) => {
        if (!precomputedItem.instruction) {
            throw new Error('No instruction found for item while cloning product')
        }

        return {
            ...precomputedItem.instruction,
            itemId: precomputedItem.newId,
            newId: UUID(),
        }
    })

    /**
     *  Executing the clone steps
    **/

    const { id: productId } = await orm.product.create({
        data: {
            id: precomputedProduct.newId,
            name: input.name,
        },
        select: {
            id: true,
        },
    })

    await orm.process.createMany({
        data: precomputedProcesses.map((precomputedProcess) => {
            return {
                id: precomputedProcess.newId,
                name: precomputedProcess.name,
                productFk: precomputedProduct.newId,
            }
        }),
    })

    await orm.assemblyProcess.createMany({
        data: precomputedAssemblyProcesses.map((precomputedAssemblyProcess) => {
            return {
                id: precomputedAssemblyProcess.newId,
                name: precomputedAssemblyProcess.name,
                productFk: precomputedProduct.newId,
            }
        }),
    })

    await orm.item.createMany({
        data: precomputedItems.map((precomputedItem) => {
            const newProcess = precomputedProcesses.find((precomputedProcess) => {
                return precomputedProcess.id === precomputedItem.process.id
            })

            if (!newProcess) {
                throw new Error('Attempted to attach a non-existent process to an item while cloning product.')
            }

            const newAssemblyProcess = precomputedAssemblyProcesses.find((precomputedAssemblyProcess) => {
                return precomputedAssemblyProcess.id === precomputedItem.assemblyProcess.id
            })

            if (!newAssemblyProcess) {
                // eslint-disable-next-line max-len
                throw new Error('Attempted to attach a non-existent assembly process to an item while cloning product.')
            }

            return {
                applicability: precomputedItem.applicability,
                assemblyProcessFk: newAssemblyProcess.newId,
                id: precomputedItem.newId,
                inspectionMethodFk: precomputedItem.inspectionMethod.id,
                name: precomputedItem.name,
                number: precomputedItem.number,
                processFk: newProcess.newId,
                sectionFk: precomputedItem.section.id,
                sequenceNumber: precomputedItem.sequenceNumber,
            }
        }),
    })

    await orm.criteria.createMany({
        data: precomputedCriteria.map((precomputedSingleCriteria) => {
            return {
                description: precomputedSingleCriteria.description,
                id: precomputedSingleCriteria.newId,
                itemFk: precomputedSingleCriteria.itemId,
            }
        }),
    })

    await orm.instruction.createMany({
        data: precomputedInstructions.map((precomputedInstruction) => {
            return {
                description: precomputedInstruction.description,
                id: precomputedInstruction.newId,
                itemFk: precomputedInstruction.itemId,
            }
        }),
    })

    const createCriteriaPromises = precomputedCriteria.flatMap((precomputedSingleCriteria) => {
        return precomputedSingleCriteria.images.map((image) => {
            return orm.image.create({
                data: {
                    criteria: {
                        connect: {
                            id: precomputedSingleCriteria.newId,
                        },
                    },
                    url: image.url,
                },
            })
        })
    })

    await Promise.all(createCriteriaPromises)

    const createInstructionPromises = precomputedInstructions.flatMap((precomputedSingleInstruction) => {
        return precomputedSingleInstruction.images.map((image) => {
            return orm.image.create({
                data: {
                    instructions: {
                        connect: {
                            id: precomputedSingleInstruction.newId,
                        },
                    },
                    url: image.url,
                },
            })
        })
    })

    await Promise.all(createInstructionPromises)

    const createdProduct = await orm.product.findUnique({
        select: PRODUCT_DEFAULT_SELECT(),
        where: {
            id: productId,
        },
    })

    if (!createdProduct) {
        throw new Error(`Couldn't find cloned product by ID: ${productId}`)
    }

    return {
        product: createdProduct,
    }
  }

The problem we encountered with this approach was creating images. Since criteria <=> images relation is many to many we can't just say:
prisma.image.createMany({
    data: {
        name: "test",
        criteriaFk: "some key'
    }
})

There may be some alternative way to do this and I'm happy to hear feedback, but currently, I'm unaware of a more efficient way.

We have another very similar example to this one but I don't want to go into detail since the premise is the same.
Let me know if something is unclear of if I can provide additional info.

Any updates on oficial support?

any updates?

In our case it would make seeding the DB with dummy data much easier to write/maintain instead of the forof loops that we currently use.

++ major blocker for our project

+1

+1 This would definitely save a lot of time in development!

This is a much needed feature. Support connect and nested relations in createMany.

+1 Would be great to have this

All feature requests that are still open are considered by the team. But as you can see, there are many of those. Hence it might take some time to really get to this one. On the other hand, it has a lot of upvotes and comments - so this is definitely higher on that list than others. More comments with uses cases and information is always welcome and will help us to decide if an issue is worth going deeper into when we look for new things to work on.

Here is my current flow that is limited by not having nested createMany.
Take the following database structure:

The use case is the following:
The diagram above represents some kind of template. There is a feature that allows the user to clone that template for whatever reason.
For each product, there would be around 5 processes, each process would have around 200 items, each item would have 1 criteria, 1 instruction, both criteria and instruction have 1 or more images.
If we do some math it would amount to this:
1 product
5 processes
1.000 items (5 processes X 200 items)
1.000 criteria (total items X 1)
1.000 instructions (total items X 1)
4.000 images ((total criteria X 2) + (total instructions X 2)) // If we assume each criteria and instruction will have 2 images
In total this would be around 7.000 entities that need to be created at once.
Plus criteria <=> images and instruction <=>= images are many to many relations so that would add even more creations to the total sum.
We could utilize the create on an entity like so:
prisma.process.createMany({
    data: {
        name: 'test',
        items: {
           create: [ /* array of items to create*/ ]
        }
    }
})

But that ends up doing INSERT for each entity and the end result is incredibly slow. 3.5 minutes as of the last testing.
So we ended up precomputing the IDs and then connecting them all together. Ideally this would be in a transaction but I haven't gotten to that yet.
public async clone(input: CloneProductInput): Promise<CloneProductPayload> {
    const existingProduct = await orm.product.findUnique({
        select: PRODUCT_DEFAULT_SELECT(),
        where: {
            id: input.id,
        },
    })

    if (!existingProduct) {
        throw new Error(`Attempted to clone non-existent product by ID: ${input.id}`)
    }

    /**
     *  Precomputing IDs
    **/

    const precomputedProduct = {
        ...existingProduct,
        newId: UUID(),
    }

    const precomputedProcesses = existingProduct.processes.map((process) => {
        return {
            ...process,
            newId: UUID(),
        }
    })

    const precomputedAssemblyProcesses = existingProduct.assemblyProcesses.map((assemblyProcess) => {
        return {
            ...assemblyProcess,
            newId: UUID(),
        }
    })

    const precomputedItems = existingProduct.processes.flatMap((process) => {
        return process.items.map((item) => {
            return {
                ...item,
                newId: UUID(),
            }
        })
    })

    const precomputedCriteria = precomputedItems.flatMap((precomputedItem) => {
        if (!precomputedItem.criteria) {
            throw new Error('No criteria found for item while cloning product')
        }

        return {
            ...precomputedItem.criteria,
            itemId: precomputedItem.newId,
            newId: UUID(),
        }
    })

    const precomputedInstructions = precomputedItems.flatMap((precomputedItem) => {
        if (!precomputedItem.instruction) {
            throw new Error('No instruction found for item while cloning product')
        }

        return {
            ...precomputedItem.instruction,
            itemId: precomputedItem.newId,
            newId: UUID(),
        }
    })

    /**
     *  Executing the clone steps
    **/

    const { id: productId } = await orm.product.create({
        data: {
            id: precomputedProduct.newId,
            name: input.name,
        },
        select: {
            id: true,
        },
    })

    await orm.process.createMany({
        data: precomputedProcesses.map((precomputedProcess) => {
            return {
                id: precomputedProcess.newId,
                name: precomputedProcess.name,
                productFk: precomputedProduct.newId,
            }
        }),
    })

    await orm.assemblyProcess.createMany({
        data: precomputedAssemblyProcesses.map((precomputedAssemblyProcess) => {
            return {
                id: precomputedAssemblyProcess.newId,
                name: precomputedAssemblyProcess.name,
                productFk: precomputedProduct.newId,
            }
        }),
    })

    await orm.item.createMany({
        data: precomputedItems.map((precomputedItem) => {
            const newProcess = precomputedProcesses.find((precomputedProcess) => {
                return precomputedProcess.id === precomputedItem.process.id
            })

            if (!newProcess) {
                throw new Error('Attempted to attach a non-existent process to an item while cloning product.')
            }

            const newAssemblyProcess = precomputedAssemblyProcesses.find((precomputedAssemblyProcess) => {
                return precomputedAssemblyProcess.id === precomputedItem.assemblyProcess.id
            })

            if (!newAssemblyProcess) {
                // eslint-disable-next-line max-len
                throw new Error('Attempted to attach a non-existent assembly process to an item while cloning product.')
            }

            return {
                applicability: precomputedItem.applicability,
                assemblyProcessFk: newAssemblyProcess.newId,
                id: precomputedItem.newId,
                inspectionMethodFk: precomputedItem.inspectionMethod.id,
                name: precomputedItem.name,
                number: precomputedItem.number,
                processFk: newProcess.newId,
                sectionFk: precomputedItem.section.id,
                sequenceNumber: precomputedItem.sequenceNumber,
            }
        }),
    })

    await orm.criteria.createMany({
        data: precomputedCriteria.map((precomputedSingleCriteria) => {
            return {
                description: precomputedSingleCriteria.description,
                id: precomputedSingleCriteria.newId,
                itemFk: precomputedSingleCriteria.itemId,
            }
        }),
    })

    await orm.instruction.createMany({
        data: precomputedInstructions.map((precomputedInstruction) => {
            return {
                description: precomputedInstruction.description,
                id: precomputedInstruction.newId,
                itemFk: precomputedInstruction.itemId,
            }
        }),
    })

    const createCriteriaPromises = precomputedCriteria.flatMap((precomputedSingleCriteria) => {
        return precomputedSingleCriteria.images.map((image) => {
            return orm.image.create({
                data: {
                    criteria: {
                        connect: {
                            id: precomputedSingleCriteria.newId,
                        },
                    },
                    url: image.url,
                },
            })
        })
    })

    await Promise.all(createCriteriaPromises)

    const createInstructionPromises = precomputedInstructions.flatMap((precomputedSingleInstruction) => {
        return precomputedSingleInstruction.images.map((image) => {
            return orm.image.create({
                data: {
                    instructions: {
                        connect: {
                            id: precomputedSingleInstruction.newId,
                        },
                    },
                    url: image.url,
                },
            })
        })
    })

    await Promise.all(createInstructionPromises)

    const createdProduct = await orm.product.findUnique({
        select: PRODUCT_DEFAULT_SELECT(),
        where: {
            id: productId,
        },
    })

    if (!createdProduct) {
        throw new Error(`Couldn't find cloned product by ID: ${productId}`)
    }

    return {
        product: createdProduct,
    }
  }

The problem we encountered with this approach was creating images. Since criteria <=> images relation is many to many we can't just say:
prisma.image.createMany({
    data: {
        name: "test",
        criteriaFk: "some key'
    }
})

There may be some alternative way to do this and I'm happy to hear feedback, but currently, I'm unaware of a more efficient way.
This is how it's currently solved but that again creates images one by one:
const createCriteriaPromises = precomputedCriteria.flatMap((precomputedSingleCriteria) => {
    return precomputedSingleCriteria.images.map((image) => {
        return orm.image.create({
            data: {
                criteria: {
                    connect: {
                        id: precomputedSingleCriteria.newId,
                    },
                },
                url: image.url,
            },
        })
    })
})

await Promise.all(createCriteriaPromises)

We have another very similar example to this one but I don't want to go into detail since the premise is the same.
Let me know if something is unclear of if I can provide additional info.

This makes sense as you have no autonumber IDs. What was the improved execution time?

+1, I absolutely need this for my use case (inserting nested JSON data into tables).

I'm currently shifting my db from mongodb to an SQL based database using prisma and this would be super helpful for migrating all my data.

This would be awesome.
My use case is seeding the database in development for a new project. I have a bunch of company and category data, and would like to insert all companies with their nested categories at the same time. Is there a current workaround for this? I imagine I have to insert all of them individually.

As a workaround for this, the most correct solution that I found is using an interactive transaction, which allows you to create records and use the result in the next create, all inside the same transaction

Just here to jump on the bandwagon—this would be an amazing feature and would help immensely when seeding. I'm grateful for these workarounds that were shared, but they aren't actual solutions. Manually inserting and connecting 1000+ records is as awful as it sounds.

This feature is much needed!  It would hugely increase the performance!

+1 Had to create ~10000 rows & it was painful af. 😅

+1 :)

+1, need this in my project and nested updateMany as well

+1 Just ran into this. It would be so sweet!

+1

Another +1 coming in!

STOP SPAMMING and just follow the issue!!

It was literally encouraged to show support in order to determine priority.

+1

+1

+1

It was literally encouraged to show support in order to determine priority.

Not really. There is a difference between giving a 👍 on the original issue, or leaving a comment that explains your unique use case - and really just leaving a +1 comment. Those are always unnecessary and we really do not want or need those.

My use case is the following:

Create one "Person" record
Create many "ID File" records associated with that user record.
For each file, create one "Permissions" record that shows who has permission to access the file.

This is not served by the $transaction API, since I need the ID of the "Person" record in order to create the Files.
Is there any workaround for this in Prisma?

This is not served by nested writes with createMany because the Files have child "Permission" records.
This is not served by the $transaction API, since I need the ID of the "Person" record in order to create the Files.
Is there any workaround for this in Prisma?

@yaacov-commenda Could this be solved by using the Interactive Transaction API?

+1

As per the request of @nikolasburk:
I would also like nested relations in createMany/updateMany.
My use case is that I read in lots of objects via an API, and each object has a list of ids of other objects that they are related to.
eg. {id: 1, relatedIds: [2, 23, 48]}
These may or may not exist at the time of creation.
Ideally, I'd be able to createMany and "connect if exists" and ignore if it doesn't, but failing that, being able to updateMany with a filtered list of ids per object would be amazing.
At the moment, I'm using transactions, so I at least don't have to iterate over 1000s of objects and await each one.

using interactive transactions seems to be a "correct" way, but is it faster to use interaction transaction or does it only guarantees that it runs as a transaction on the database?

I wanted to add my use case as well
I'm working in the e-com space and would like to create a product as follows:
When creating a product, at least one product variant must be added. Products has one-to-many relation with Variants.
When creating a product variant. Exactly one price must be added. Variant has one-to-one relation with Price.
The problem I'm facing is exactly what the issue describes, I can't create a product with nested variant (createMany) with nested price (one price)
Here's my schema for reference
model Price {
  id             Int      @id @default(autoincrement())
  centAmount     Int
  currencyCode   Currency @default(EUR)
  fractionDigits Int      @default(2)
  variant        Variant  @relation(fields: [variantId], references: [id], onDelete: Cascade, onUpdate: Cascade)
  variantId      Int      @unique
}

model Variant {
  id    Int    @id @default(autoincrement())
  sku   String @unique
  price Price? // Here is the issue
  product   Product @relation(fields: [productId], references: [id], onDelete: Cascade, onUpdate: Cascade)
  productId Int
}

model Product {
  id          Int       @id @default(autoincrement())
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt
  name        String
  description String?
  productKey  String?
  variants    Variant[]
  version     Int       @default(1)
}

And here's the prisma command
const { name, variants, description, productKey } = ProductDraftSchema.parse(req.body);

    const product = await prisma.product.create({
      data: {
        name,
        productKey,
        description,
        variants: {
          createMany: {
            data: variants,
          },
        },
      },
      include: {
        variants: true,
      },
    });

I wanted to add my use case as well
I'm working in the e-com space and would like to create a product as follows:
When creating a product, at least one product variant must be added. Products has one-to-many relation with Variants.
When creating a product variant. Exactly one price must be added. Variant has one-to-one relation with Price.
The problem I'm facing is exactly what the issue describes, I can't create a product with nested variant (createMany) with nested price (one price)
Here's my schema for reference
model Price {
  id             Int      @id @default(autoincrement())
  centAmount     Int
  currencyCode   Currency @default(EUR)
  fractionDigits Int      @default(2)
  variant        Variant  @relation(fields: [variantId], references: [id], onDelete: Cascade, onUpdate: Cascade)
  variantId      Int      @unique
}

model Variant {
  id    Int    @id @default(autoincrement())
  sku   String @unique
  price Price? // Here is the issue
  product   Product @relation(fields: [productId], references: [id], onDelete: Cascade, onUpdate: Cascade)
  productId Int
}

model Product {
  id          Int       @id @default(autoincrement())
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt
  name        String
  description String?
  productKey  String?
  variants    Variant[]
  version     Int       @default(1)
}

And here's the prisma command
const { name, variants, description, productKey } = ProductDraftSchema.parse(req.body);

    const product = await prisma.product.create({
      data: {
        name,
        productKey,
        description,
        variants: {
          createMany: {
            data: variants,
          },
        },
      },
      include: {
        variants: true,
      },
    });

I would also like to add my use case.
I am building a workflow dashboard
I have User, Workspace, Stage, Task, Comment structure.
When creating a Stage it is possible to connect it to a Workspace, User & create nested Tasks. The nested Tasks can also be connected to a User & Comments. The nested Comments can be connected to a User

Please add a warning if you will not add this feature!
Perhaps a tangent to/from this thread, but please can we get type warnings about this. If you are not going to add the feature please provide better warning messages that Prisma does not support createMany in createMany.
It would alleviate a lot of the frustration contained in this thread if we had a polite 'coming soon' message rather than X is not assignable to type Y
I love prisma and keep forgetting about this issue and finding it later!

+1, it sounds logical and will be very useful for my project

What is the work around for this since it appears a nested createMany is still not a feature?

@GoffAC Can you turn that suggestion into its own issue? That is a good idea (although I have no idea if we can differentiate that granular - I hope so).
@danlubbers All of it. For now I know that it would make sense to have nested writes in createMany, but no idea why we don't yet and what it would take to implement that. I bet there are weird side effects because of the Many that we need to identify and then mitigate.

What is the work around for this since it appears a nested createMany is still not a feature?

try generating Id's outside of the db, then I think Prisma could handle the rest in some sort of transaction. Haven't tried it myself.

What is the work around for this since it appears a nested createMany is still not a feature?

try generating Id's outside of the db, then I think Prisma could handle the rest in some sort of transaction. Haven't tried it myself.

This is what I did. Generate the IDs manually ahead of time and then batch insert records without nesting.

What is the work around for this since it appears a nested createMany is still not a feature?

try generating Id's outside of the db, then I think Prisma could handle the rest in some sort of transaction. Haven't tried it myself.

This is what I did. Generate the IDs manually ahead of time and then batch insert records without nesting.

I appreciate this. It's a good workaround for me for now. Sucks that it still requires multiple create calls though.
However, (+1) my use case would really benefit from Prisma automatically creating any "requisite" objects/relations that are nested within a createMany: { statement. I tried to dynamically "layer" create: { statements into my DTOs and I could not find any way to do it that satisfied Priisma's type requirements.
Specifically, my ApplicationDetails model has a one-to-many relationship with a Reference model, which contains a Contact model, which optionally contains an Address model. I would expect to be able to create these all in one function call.

What is the work around for this since it appears a nested createMany is still not a feature?

try generating Id's outside of the db, then I think Prisma could handle the rest in some sort of transaction. Haven't tried it myself.

This is what I did. Generate the IDs manually ahead of time and then batch insert records without nesting.

I appreciate this. It's a good workaround for me for now. Sucks that it still requires multiple create calls though.
However, (+1) my use case would really benefit from Prisma automatically creating any "requisite" objects/relations that are nested within a createMany: { statement. I tried to dynamically "layer" create: { statements into my DTOs and I could not find any way to do it that satisfied Prisma's type requirements.
Specifically, for example, my ApplicationDetails model has a one-to-many relationship with a Reference model, which contains a Contact model, which optionally contains an Address model. I would expect to be able to create these all in one function call.

I think it's too late for Prisma to change the design of nested writes at this moment. I think it was a bad design.
I just wish someone can build an Abstraction layer over Prisma to take in full JSON objects with their relations, just like Sequelize.
Don't know if it's possible with Prisma Extensions

I think it's too late for Prisma to change the design of nested writes at this moment. I think it was a bad design.

It's never too late for anything. And often we could offer both as valid option.

I just wish someone can build an Abstraction layer over Prisma to take in full JSON objects with their relations, just like Sequelize.

Is this spelled out in this thread already exactly what you mean by that and how it would work? That would be really helpful it this is a potential option on how to deal with the problem this issue is about. Thanks.

+1

This is a fairly large gap in Prisma IMO and is something that is offered by competitors such as Typeorm. It seems odd to me that reads are capable of getting the nested data but writes are not. Very thankful for all the hard work on Prisma and would for this to be a prioritized feature.

Do they have a plan to implement this in the future?

need this feature

Do they have a plan to implement this in the future?

It's been two years, so my guess is a quiet no lol

No, a totally not quiet "Not right now, as we are busy with other things and can not do all the things with the capacity we have. If this was a 'no', we would have closed the issue.".

bump

I'm really starting to see the cracks in Prisma now that I have worked a lot with it.
aggregate only on one table at a time
and create many you can't insert in deep ????? WTH Prisma

Sounds like a good first issue.

I'm really starting to see the cracks in Prisma now that I have worked a lot with it.
aggregate only on one table at a time
and create many you can't insert in deep ????? WTH Prisma

We could label the "cracks" of prisma. Personally I find that handling multiple creates/

In my personal experience for using Prisma for a long time, nested writes are only really useful on writing seed files because it makes it much easier to do (so it's desirable to see it being implemented).
In a production manner, I haven't seen the need for this yet.

In my personal experience for using Prisma for a long time, nested writes are only really useful on writing seed files because it makes it much easier to do (so it's desirable to see it being implemented).
In a production manner, I haven't seen the need for this yet.

For complex data structures it most certainly is needed to reduce the number of roundtrips and improve performance.

Prisma is pretty great except for this. I feel like I either need to go with the features that sequelize supports or the type safety that Prisma supports, so I'm left disappointed in one way or another.

The fact that this is ongoing for so long... I came upon this thread as I also need this functionality.

+1'ing this is critical for us as well.

👍 As this feature is impacting me rn

+1, this would be nice to have with Prisma

Revisiting this after commenting in July... I really don't have a problem with the current syntax anymore. I encountered this because I was looking to be able to create multiple of something and attach all items to one related item from another table. I'd go as far as to say, at least for my case, this was a skill issue that I was able to overcome.
For example, let's say I want to add many feature items to one apartment, where features and apartments have a many-to-many relationship, and the feature name is unique.  It's actually really quite simple to do using map, and the typesense in maintained:
            const apartment = await prisma.apartment.create({
                data: {
                    // ...
                    features: {
                        create: features.map(featureName => (
                                {
                                    feature: {
                                        connectOrCreate: {
                                            where: { name: featureName },
                                            create: { name: featureName }
                                        }
                                    }
                                }
                            )),
                    }
                }
            });

@Nmans01 thanks for sharing that approach! Curious to know — does it work with createMany?

@Nmans01 It looks nice and clean, I'll definetely copy that 🙂. Although my understanding is that the issue is with efficiency, and not so much with syntax. I guess this approach would still produce individual CREATE/UPDATESs on the database level? (I don't have the insights into the inner workins of Prisma to tell 🫤)

We have significantly optimised create operation in Prisma 5.11.0. Now for the deepest level of nesting, the create operation is executed in bulk using much fewer queries than before.
@yousufhasan does that address your initial problem with query efficiency?

@laplab I can't speak to whether it has helped for others, but I can say that it has not caused any significant improvements for me.
I have a pretty large table with currently around 60 basic (string, number, boolean) columns, and about 10 relations.
We allow users to do bulk-updates by uploading an excel sheet where they can specify these columns and relations. These excel sheets often contain thousands of rows.
We then take this excel sheet and either update existing records or create new records for each row.
Since we also support updating relation this way, and because the columns will likely contain different values per row, we cannot use updateMany or createMany.
We are currently creating an interactive prisma transaction, iterating each row and mapping it to a prisma.update or prisma.create call, collecting them and await Promise.all'ing them within the transaction function.
This has been extremely slow, to the point where I managed to take down our entire staging environment today by running it with an excel with ~2000 rows.
I have managed to get around the performance issue in a smaller import that operates on a much smaller table where we only need up update a few (<10) basic columns by first creating a temp table that is an copy of the original table, createMany'ing into that table, and then using a queryRaw to perform an UPDATE JOIN (not sure if that's an official term) on these tables, which is very fast, even for 1000s of rows.
However, that is not going to work for the more complicated import since we also need to update relations.

Did this ever get addressed? Reading through the thread it doesn't seem like it.

@raymondKelly Currently working through input here, do you have a link to how TypeORM does this? Thanks.

Hi @janpio its been a while since I've touched TypeORM so I'll need to refresh my memory and dig into their docs again. Are you looking for how they structure their entities or are you looking for the code that build the query for the nested relationships?

Yes, all of that. We are trying to understand how others implement the API necessary, and of course also how they translater that to efficient SQL queries that are hopefully more effective than just looping over the entries-to-be-created manually. Appreciate it.

Edit: to really highlight the "fix" here, its that the create nested property can take an array as input, which itself can have nested relations. It seems strange that the createMany property doesn't support the same.
Original: Revisiting this after commenting in July... I really don't have a problem with the current syntax anymore. I encountered this Issue because I was looking to be able to create multiple of something and attach all items to one related item from another table. I'd go as far as to say, at least for my case, this was a skill issue that I was able to overcome.
For example, let's say I want to add many feature items to one apartment, where features and apartments have a many-to-many relationship, and the feature name is unique. It's actually really quite simple to do using map, and the typesense is maintained:
            const apartment = await prisma.apartment.create({
                data: {
                    // ...
                    features: {
                        create: features.map(featureName => (
                                {
                                    feature: {
                                        connectOrCreate: {
                                            where: { name: featureName },
                                            create: { name: featureName }
                                        }
                                    }
                                }
                            )),
                    }
                }
            });

Any thoughts on what's highlighted in the edit?

Edit: to really highlight the "fix" here, its that the create nested property can take an array as input, which itself can have nested relations. It seems strange that the createMany property doesn't support the same.

createMany() also promises you that it runs the queries with the minimal number of SQL queries - without relations that is often just 1, that combines all the values in the list. When you add relations to the story though, it becomes more difficult because you have to map both the main model and the relations models to each other and make sure all the relations are correct. Our code is not designed for that yet. And if we just take the logic from create(), and put it into createMany() to allow it to take multiple main model entries, that would lead to at least 1 query per entry plus one or some for the relations.
But we are making good progress in figuring this out and hope to be able to start implementation of some functionality here soon.

To help with our decision-making, a small emoji poll for everyone subscribed to this issue.
React with the following emoji depending on your preference:

🚀 = I just want the createMany() API to accept a list of entries with relations, and do not necessarily need the SQL queries to be fully optimized from the beginning.
🎉 = I want the above, but also absolutely need the SQL queries to be highly optimized from the beginning.

Thanks for your reaction votes.

@janpio What is the key difference between 1 and 2 in regards to shipping it? Time to develop or breaking changes in the api (Like if you go with option 2, then createMany's options would need to change somehow)?

1. 🚀 = I just want the `createMany()` API to accept a list of entries with relations, and do not necessarily need the SQL queries to be fully optimized from the beginning.

What would be the difference between this option and calling create through a related model with an array? Or wild this solely impact the prismaClient.X.createMany() API?

@janpio What is the key difference between 1 and 2 in regards to shipping it? Time to develop or breaking changes in the api (Like if you go with option 2, then createMany's options would need to change somehow)?

@muchisx Purely about expectation from you. (2) is obviously a lot more work, as it requires (1) and then a lot more, so will take longer. Unfortunately the vote is quite clear that (2) is preferred and (1) would probably not be adequate.

What would be the difference between this option and calling create through a related model with an array? Or wild this solely impact the prismaClient.X.createMany() API?

@Katli95 The new API would allow createMany() to take a list of items with nested relations, so like create() - but with a list instead of a single item. So you do not have to loop over a list of items manually anymore, and call create() one by one. Or did you have something else in mind?

do we have any news on this?

This would be reallt useful. Came across this thread and running through the same issue as everyone here,

This would be super useful!

It would be also useful for the createManyAndReturn function. Currently you are only allowed to add the foreign keys and you have to query them before in the database instead of just creating them in a nested createManyAndReturn operation. Hope it will be implemented in the next time. :)

Aguardando solução

It's remarkable to me that this feature request has had so much engagement, yet has not been delivered in 3.5 years – especially as the ORM landscape has become much more competitive in that period of time, and this use case is serviced by nearly all competitors
Nested relations in createMany is not just about seeding or development. There are countless production use cases where hundreds or thousands of rows need to be written as quickly as possible, and contain nested many-to-many relations.
In my experience, the performance difference when having to rely on a sequential .create loop instead of using .createMany is in the 100-1000x worse range.
I think it was a mistake for @janpio to ask the group if they wanted the feature to be "highly optimized from the beginning". Just write a rough draft and release it as experimental! Something is better than nothing, perfect is the enemy of good.
Prisma has now released TypedSQL.
Perhaps we should now use this thread to help ourselves/each other, instead of waiting for help.

I will give an explanation of how I side-stepped this issue recently, on a project that required bulk inserts of thousands of rows with various 1:1 and 1:many relations.
The key point: explicit/self-managed relation tables.
Let's assume I am fetching scientific publications in bulk batches of 1000 – this is a contrived example.
Primarily, I want to write the publications to a Publication table, but I also need to manage authors.
There are two kinds of relations:

primaryAuthor – this is a 1:1 relation between Publication and PublicationAuthor
coAuthors – this is a 1:many relation between Publication and PublicationAuthor

Our models would look like this:
model Publication {
  primaryAuthor   PublicationAuthor     @relation(fields: [primaryAuthorId], references: [id])
  primaryAuthorId String                @db.Uuid
  coAuthors       PublicationCoAuthor[]
}

model PublicationAuthor {
  name                 String
  primaryPublications  Publication[]
  coAuthorPublications PublicationCoAuthor[]
}

model PublicationCoAuthor {
  publication   Publication       @relation(fields: [publicationId], references: [id]
  publicationId String            @unique @db.Uuid
  author        PublicationAuthor @relation(fields: [authorId], references: [id])
  authorId      String            @db.Uuid
}

My bulk creation process can then look like:
// Step 1: Create all authors
const authors = await prisma.publicationAuthor.createManyAndReturn({
  data: [...],
  skipDuplicates: true,
})

// Step 2: Create all publications with primaryAuthor relations
const publications = await prisma.publication.createManyAndReturn({
  data: [
    {
      ...,
      primaryAuthorId: authors.find(...)
    }
  ],
})

// Step 3: Create 1:many coAuthor relations
await prisma.publicationCoAuthor.createMany({
  data: [...]
})

Of course these three steps can be wrapped in an interactive transaction if desired.
The performance difference between this approach, and a for-loop using .create for each row, is literally just about 1*N where N is your number of rows – it is completely untenable.
In other words, Prisma has fully dropped the ball on this, but it's possible to "fix" it yourself without having to actually maintain raw SQL queries.

any update please?

@isaachinman this is a crucial point and should be addressed by the prisma team. Since the developer has to provide concrete ids, createManyAndReturn is only usable for absolutely rare use cases, where the ids in the relation has to be known. Otherwise i still have to prefer raw cte sql queries in postgres. In example  you want to create multiple publications and you got 1000 of publications with their related primary author names. Asume there are 800 authors involved,. You do not want to query the authors in the database, just to get their ids. Even if you use the in query and get all author names in one run, you still have to go in memory through all the list, just to find the primary author id for each record.
Only if the developer is able to nest the created/connected relations, in example like that it becomes useful:
const publications = await prisma.publication.createManyAndReturn({
  data: [
    {
      ...,
      primaryAuthor: {
         name: "John" // should be created if not exist
      }
    },
    {
      ...,
      primaryAuthor: {
         name: "Jessy"
      }
   },
   {
      ...,
      primaryAuthor: {
         name: "John" // John again. If name is unique I would expect that it crates him only one time and connects him with the publication
      }
   }
  ],
})

And this is also in general.useful for createMany operations, not just for the create many and return.
It also would be useful to nest connect, connectOrCreate if a foreign key is part of a unique constraint in the connected and relates table. There you also have the same problem and have to provide the exact foreign key.
For real business scenarios and bulk operations I use plain raw sql with full control. Depending on the use case it becomes a bit hard to prevent queryRawUnsafe. A Prisma.join, Prisma.Sql helps out here, but for newcomers, it is overwhelming. Hope prisma will provide a more convenient way, since this ticket is now open for 2 years.


currentOptions uninitialized (Vite)

Describe the bug
I'm using Vite and<EMAIL_ADDRESS>and the browser is printing this error:

(See https://github.com/vuejs/vue-apollo/blob/v4/packages/vue-apollo-composable/src/useQuery.ts#L358)
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Versions
vue: next
vue-apollo: 4.0.0-alpha.13
apollo-client: 3.3.20

The temporal solution is downgrade to vue-apollo 4.0.0-alpha.12

Same error when using @nuxtjs/apollo 4.0.1-rc.5 and @nuxtjs/composition-api 0.24.6

Also having this issue with @nuxtjs/apollo 4.0.1-rc.5  and @nuxtjs/composition-api 0.24.6, though it does work client side, this error only occurs during SSR

Thx to this PR #1218 im currently using a postinstall script which moves the currentOptions up to the correct position.
scripts/vue-apollo-patch.js
const fs = require('fs');
const path = require('path');

const indexEsmPath = path.resolve(
  __dirname,
<EMAIL_ADDRESS>);

fs.writeFileSync(
  indexEsmPath,
  fs
    .readFileSync(indexEsmPath, 'utf8')
    .replace(/const currentOptions = ref3\(\);/, '')
    .replace(
      /const documentRef = paramToRef\(document\);/,
      'const currentOptions = ref3();\nconst documentRef = paramToRef(document);'
    )
);

const indexPath = path.resolve(
  __dirname,
<EMAIL_ADDRESS>);

fs.writeFileSync(
  indexPath,
  fs
    .readFileSync(indexPath, 'utf8')
    .replace(/const currentOptions = \(0, import_vue_demi8\.ref\)\(\);/, '')
    .replace(
      /const documentRef = paramToRef\(document\);/,
      'const currentOptions = (0, import_vue_demi8.ref)();\nconst documentRef = paramToRef(document);'
    )
);

package.json
{
    "scripts": {
        "postinstall": "node scripts/vue-apollo-patch.js"
    }
}

Hope this helps.

I updated the script which should move all currentOptions to the correct position.
const fs = require('fs');
const path = require('path');

const indexEsmPath = path.resolve(
  __dirname,
<EMAIL_ADDRESS>);

fs.writeFileSync(
  indexEsmPath,
  fs
    .readFileSync(indexEsmPath, 'utf8')
    .replace(/const currentOptions = ref3\(\);/, '')
    .replace(
      /const vm = getCurrentInstance3\(\);/,
      'const vm = getCurrentInstance3();\nconst currentOptions = ref3();'
    )
    .replace(/const currentOptions = ref5\(\);/, '')
    .replace(
      /const vm = getCurrentInstance5\(\);/,
      'const vm = getCurrentInstance5();\nconst currentOptions = ref5();'
    )
);

const indexPath = path.resolve(
  __dirname,
<EMAIL_ADDRESS>);

fs.writeFileSync(
  indexPath,
  fs
    .readFileSync(indexPath, 'utf8')
    .replace(/const currentOptions = \(0, import_vue_demi8\.ref\)\(\);/, '')
    .replace(
      /const vm = \(0, import_vue_demi8\.getCurrentInstance\)\(\);/,
      'const vm = (0, import_vue_demi8.getCurrentInstance)();\nconst currentOptions = (0, import_vue_demi8.ref)();'
    )
    .replace(/const currentOptions = \(0, import_vue_demi5\.ref\)\(\);/, '')
    .replace(
      /const vm = \(0, import_vue_demi5\.getCurrentInstance\)\(\);/,
      'const vm = (0, import_vue_demi5.getCurrentInstance)();\nconst currentOptions = (0, import_vue_demi5.ref)();'
    )
);

I see the same thing

Can confirm it was just fixed in 4.0.0-alpha.14 👍


feat(vue-pepicons): add -square wrap

might be cool to have the ability to make any icon easily renderable as icon like these:

-circle
-round
-off
-circle-off

are released in v2
https://github.com/CyCraft/pepicons/releases/tag/v2.0.0


chore: rename cypress happo project in workflows

FX-2874
Description

rename picasso project name to Picasso/Cypress inside our workflows. Main reason for that is to eliminate confusion with Picasso/Storybook project

HAPPO has a fallback mechanism for its configuration settings. I added picasso to the alternative names field so it will still catch the correct project for ongoing CI processes.

How to test

there shouldn't be a problem with our CI for cypress

Development checks

Add changeset according to guidelines (if needed)
Read CONTRIBUTING.md and Component API principles
Annotate all props in component with documentation
Create examples for component
Ensure that deployed demo has expected results and good examples
Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.
[ ] Self reviewed
Covered with tests

Breaking change

codemod is created and showcased in the changeset
test alpha package of Picasso in StaffPortal

PR commands

List of available commands:

@toptal-bot run all - Run whole pipeline
@toptal-bot run build - Check build
@toptal-bot run deploy:documentation - Deploy documentation
@toptal-bot run package:alpha-release - Release alpha version

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

Overall it looks good, but I have 2 questions. Will a new project be created on Happo's side? How will they know that we are just renaming it?

I have already replied to your question in the description of the PR. I have already renamed the project on Happo side.

Yeah. I jumped into the code and didn't look at the description. :facepalm: I'll try to be more careful next time, not ask already answered questions. Thanks Oz! :bow:

There's one more thing you need to change, though. Required checks. I am already getting an error on the TreeView PR.

Hmm, in this case, we should merge this one fast to not block others 🤔 I wasn't aware of that


Allow to run queries from [Explore] tab in grafana

Cannot run query from Expore tab in grafana.

Example of get command (cannot edit the key at all):

Also cannot run clusterINFO command

Describe the solution you'd like
To be able to run queries from Expore tab the same as inside grafana dashboard widgets.
Additional context
It works well in dashboard widgets but not with the expore mode.
Thanks

@shay-berman Please check that Redis datasource configured correctly, I was able to use Explore using the latest release and configured Redis Data Source.
Regarding key looks like it intersects with one of the reserved variables. I will look into it and may need to rename it.

@shay-berman Thank you for opening the issue. The Key was updated to KeyName to avoid conflict with reserved option in the Grafana Explore.


[FEATURE] Set up translations for docs

Is your feature request related to a problem
Nope.
Several community members have proposed and offered help adding translations to other languages.
Portuguese: #921
Chinese: discussed with https://twitter.com/linupy1 on Twitter
Spanish: at least I would do it, I hope others would be willing to help :smile:
The solution you would like
I have to set up a simple way to add translations.
I think it will be adding a copy of the same MkDocs files for each language and including all that on a sub path.
It will probably include copying each original English file that is not translated and adding a note about its translation.
And there should also be a way to add a note about translations that need to be re-synchronized with the original English version.
There should also probably be a note about translations being provided by the community and that the "official" version is always English.
The translation process would probably be page by page in a separated PR. That way others can review those translations in small amounts.
It would probably depend a lot on each PR getting several PR approvals by community members. I can verify and check Spanish and, to some extent, Portuguese. But for example, I don't speak Japanese, Chinese, nor Rusian. And there's a lot of content about FastAPI in those languages, I suspect those would be some of the first translations.
Describe alternatives you've considered
Not adding translations at all.
Waiting for MkDocs to have official support for translations https://github.com/mkdocs/mkdocs/issues/617 , but as this is a complex topic, I expect that to take some time. And we can have a simple version that works, at least just for FastAPI.
Additional context
:earth_africa: :man_shrugging:

@tiangolo I can help with translations to Serbian

@tiangolo I would like to help translate into Japanese.

We have it now! :earth_africa: :rocket:
Here are the new docs for contributing translations to FastAPI: https://fastapi.tiangolo.com/contributing/#translations
And I think it ended up quite easy to use/set up. :sparkles: :tada:
Thanks @pyropy , @yutayamazaki , @linupychiang, @juhovh-aiven for your offer and/or help! It's very much appreciated :cake: :earth_africa:

@tiangolo

@tiangolo
We(@Dustyposa ) have formed a small team to complete the translation of Chinese version. Interested friends are welcome to join us.

Thanks for doing it @waynerv, @Dustyposa, and everyone contributing!
If you want, feel free to create a new issue to coordinate Chinese translation and I will pin it. There's currently one for Portuguese translations https://github.com/tiangolo/fastapi/issues/1211
As we now have the translations system and workflow more or less set up I'll now close this issue.


Default keybind in rebase menu conflicts with standard movement keys

Description
In the rebase popup, k is used for an action by default. I think this is a bad idea as it's part of the standard movement keys and could easily be accidentally triggered

I'm more than willing to open a PR to fix this if it's deemed an issue.
Neovim version
NCIM v0.9.1
Build type: Release
LuaJIT 2.1.0-beta3
Operating system and version
Linux 6.4.8-arch1-1
Steps to reproduce

open neogit
press r for rebase
press k

Expected behavior
Should use some other keybind by default
Actual behavior
Described above
Minimal config
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvim/site]])
local package_root = "/tmp/nvim/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup({
    {
      "wbthomason/packer.nvim",
      {
        "TimUntersberger/neogit",
        requires = {
          { "nvim-lua/plenary.nvim" },
          { "sindrets/diffview.nvim" },
        },
        config = function()
          print("loaded neogit")
          require("neogit").setup()
        end,
      },
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  })
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing neogit and dependencies.")
  vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()

I actually disagree about the movement. It's your call at the end of the day but as far as I know the way to toggle the command flags is by moving over one and pressing TAB

Ohh, ok. Maybe I should make the docs more clear that the highlighted text next to the action/switch will trigger it.


types: Enforce length on all custom types

Our types package is lie: https://github.com/oasislabs/oasis.js/blob/master/packages/types/src/index.ts

Partly addressed by https://github.com/oasislabs/oasis.js/pull/202

This has become much more relevant due to https://github.com/oasislabs/oasis-rs/issues/184.
We can't cbor encoding Uint8Array, but instead need to use Array for Vec<u8> and Address.

The types package has been removed in https://github.com/oasislabs/oasis.js/pull/261, so this is no longer relevant.


Custom Drawer Flutter

Hey, I want to contribute to this repository by adding custom drawer in flutter.
the design of drawer is attached below.

r.

I can do that please assign it to me

assign this to me


KAFKA-9651: Fix ArithmeticException (÷ by 0) in Partitioner impls

This PR fixes KAKFA-9651 by throwing UnknownTopicOrPartitionException instead of ArithmeticException.

@cmccabe @mjsax @ewencp please could you review?

Thanks @guozhangwang, I should have remembered that about the producer.
One thing I don't understand is how using sourceTopicsInfo.maxPartitions as the num partitions (as is done by StreamsMetadataState.getKeyQueryMetadataForKey()) will result in a non-zero number of partitions, when it appears to me that both code paths will use the same Cluster metadata (or maybe I'm wrong about that).
I updated the commits if you want to take another look.

StreamPartitioner#partition  is used in two places, in the RecordCollectorImpl the caller checks that numPartitions > 0; in the StreamsMetadataState as you asked, it is depending on clusterMetadata.partitionsForTopic(topic); indeed, but as long as KafkaStreams is running we are guaranteed that the source topics' metadata are available, and hence the maxPartitions is guaranteed to be non-zero.

Thanks for the explanation.

@guozhangwang any more comments on this PR?

test this please

Thanks @guozhangwang, now fixed.


Is it possible to revive camel-quarkus-solr now that camel-solr is back in camel 4

Describe the feature here
As camel-solr was initially removed in early camel-4.x releases, the camel-quarkus-solr was removed from camel-quarkus via the commit Upgrade Camel to 4.0.0-M3.
In july this year, the camel-solr component found his way back in solr (jira ticket camel-solr: revive component and upgrade to the latest version).
Can we also revive the camel-quarkus-solr component?

We are may run into issues with the Jetty version. solr-solrj depends on Jetty 10.x. However, this project aligns with Jetty 12.x.
org.apache.camel:camel-solr:jar:4.9.0-SNAPSHOT
+- org.apache.solr:solr-solrj:jar:9.7.0:compile
|  +- org.eclipse.jetty.http2:http2-client:jar:10.0.22:compile
|  |  \- org.eclipse.jetty:jetty-alpn-client:jar:10.0.22:compile
|  +- org.eclipse.jetty:jetty-http:jar:10.0.22:compile
|  +- org.eclipse.jetty:jetty-client:jar:10.0.22:runtime
|  +- org.eclipse.jetty:jetty-util:jar:10.0.22:compile
|  +- org.eclipse.jetty:jetty-io:jar:10.0.22:compile
|  \- org.eclipse.jetty:jetty-alpn-java-client:jar:10.0.22:runtime

It needs verifying but it may not work.

Thanks for looking into this.
I was already preparing my "case files" to ask the camel project to refactor the solr component. We should be able reduce the scope of the camel-solr component and use a quite recent solrclient (HttpJdkSolrClient) that promises not to be dependent of jetty.
So I guess we should park this issue until we get the refactoring done on that side...
I'll refer to this issue when filing my "ticket" in camel.
To be continued...


AssigneeID should also accept "none" and "any"

Hey, I'd like to list unassigned issues, but to do so I'd have to pass the AssigneeID with the value "none", wich is not currently possible, given the option type definition below.
https://github.com/xanzy/go-gitlab/blob/bd30483e865c054c52179448051bef0c597a2495/issues.go#L218
So I was thinking if we could change that in a way to allow for this "any" and "none" possible values.
I'm likely to create a pull request for that sson, but as such strcuture would be quite werid (blame gitlab for that), I'd realy like to know if you guys have tackled this problem and maybe just decided to live it be.

Please checkout: https://github.com/xanzy/go-gitlab/blob/master/types.go#L133

Oh, thx
If I got it right, should we set this AssigneeIDValue as the type for AssigneeID in the ListIssuesOptions struct?
And then we could just use the UserIDNone constant here.
Or maybe I didn't get it?

Almost... The type should be *AssigneeIDValue and then you can set it using the helper function:
gitlab.AssigneeID(gitlab.UserIDNone)

Which returns a *AssigneeIDValue

Ok, thx for ur patience, PR comming soon


Writing mistake on correlation property name

Hello,
I was studying the correlation configurations on the 'Application Insights for web pages' documentation and noticed one detail that is a little confuse. The 'Enable Correlation' section has an explanation of the correlationHeaderExcludedDomains property that was written as correlationHeaderExcludeDomains. I think both are the same and was just a writing mistake.
Appreciate your attention

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

ID: d56ecb14-9e66-5313-a381-d2824ec3d1e2

Version Independent ID: ff056ac8-ae76-be10-6895-757333a28e05

Content: Azure Application Insights for JavaScript web apps - Azure Monitor

Content Source: articles/azure-monitor/app/javascript.md

Service: azure-monitor

Sub-service: application-insights

GitHub Login: @lgayhardt

Microsoft Alias: lagayhar

@MuriloOnYou Thanks for the question! We are investigating and will update you shortly.

@MuriloOnYou Thanks for catching that! correlationHeaderExcludedDomain is correct (https://github.com/microsoft/ApplicationInsights-JS#configuration). I changed  correlationHeaderExcludeDomainstocorrelationHeaderExcludedDomain`. The change should go live later today.
Thank you
#please-close


Creating files with reserved Windows file names creates issues within Windows

Your Windows build number:  Microsoft Windows [Version 10.0.15063]

What you're doing and what's happening:
echo "foobar" > con.out

This creates the file con.out in the current directory.  It is totally usable from bash.
But from DOS, you cannot look at the file, rename the file, or do anything with it, because "CON" is a reserved file name.  You cannot even rename the file from Windows Explorer.

What's wrong / what should be happening instead:
Maybe a warning should be issued if from Linux, you are creating a file that has a name that is invalid for Windows.  Or it should not be possible to create files with the reserved names.

Apparently, these are the reserved file names:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9  (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx)

This is spiritually similar to #2081. See the notes on namespaces pasted from your link below. Those names are reserved in Win32 by convention, but not the NTFS filesystem.
You could fail on the names (and similarly fail on case collisions), controlled with a DrvFS mount option as proposed here. [An option that would be off by default to avoid "why can't I echo foobar > con.out on DrvFs?" bug reports. And turned on by no one. But I digress.]

Namespaces

There are two main categories of namespace conventions used in the Windows APIs, commonly referred to as NT namespaces and the Win32 namespaces. The NT namespace was designed to be the lowest level namespace on which other subsystems and namespaces could exist, including the Win32 subsystem and, by extension, the Win32 namespaces. POSIX is another example of a subsystem in Windows that is built on top of the NT namespace. Early versions of Windows also defined several predefined, or reserved, names for certain special devices such as communications (serial and parallel) ports and the default display console as part of what is now called the NT device namespace, and are still supported in current versions of Windows for backward compatibility.

This is spiritually similar to #2081. The names are reserved by convention in Win32, but are legal NTFS filenames. See comments on namespaces from your link at the bottom.
Your ask could be provided with a DrvFs mount option (similar to disallowing case collisions) per the proposal here.

Namespaces

There are two main categories of namespace conventions used in the Windows APIs, commonly referred to as NT namespaces and the Win32 namespaces. The NT namespace was designed to be the lowest level namespace on which other subsystems and namespaces could exist, including the Win32 subsystem and, by extension, the Win32 namespaces. POSIX is another example of a subsystem in Windows that is built on top of the NT namespace. Early versions of Windows also defined several predefined, or reserved, names for certain special devices such as communications (serial and parallel) ports and the default display console as part of what is now called the NT device namespace, and are still supported in current versions of Windows for backward compatibility.

Can I request this NOT be "fixed".
I have had a problem with software that happens to be more that happy to create files with invalid names.
CMD can't touch them
Powershell can't touch them
Win32 explorer can't touch them
Trying to interact with the file using the 8:3 compatibility name does not work
Running chkdsk shows no errors
Deleting the directory one level up leaves the files behind
The files are effectively stuck and it seems there was no way to remove or rename it other than booting into Linux, mounting the drive and manipulating the file that way. Now however I can just start a bash shell and mv "invalidname.foo" win32safename.foo and everything is fine. It has been really convenient.

Can I request this NOT be "fixed". [...] It has been really convenient.

Agreed, but your line reasoning failed last time I tried to evoke the same. In ntfs-3g the mount option is called windows_names.
So, the solution seems to be to make it an obscure mount option, make posix (ie current) behaviour the default, and then never use it.
   Windows Filename Compatibility
       NTFS  supports several filename namespaces: DOS, Win32 and POSIX. While
       the ntfs-3g driver handles all of them, it always creates new files  in
       the  POSIX  namespace  for  maximum  portability  and  interoperability
       reasons.   This  means  that  filenames  are  case  sensitive  and  all
       characters  are allowed except '/' and '\0'. This is perfectly legal on
       Windows,  though  some  application  may  get  confused.   The   option
       windows_names  may  be  used  to apply Windows restrictions to new file
       names.

       windows_names
              This option prevents files, directories and extended  attributes
              to be created with a name not allowed by windows, because

                     - it contains some not allowed character,
                     - or the last character is a space or a dot,
                     - or the name is reserved.

              The forbidden characters are the nine characters " * / : < > ? \
              | and those whose code is less than 0x20, and the reserved names
              are  CON,  PRN, AUX, NUL, COM1..COM9, LPT1..LPT9, with no suffix
              or followed by a dot.

              Existing such files can still be read (and renamed).

@Vaporeon
https://gist.github.com/poizan42/9ef1cdfb16e2515b586719900072599d
https://gist.github.com/poizan42/ed45fae25e6c482a3d9fe2bdac84894b


How to start CP charging from a schedule stored in server side?

Hi, I managed to have a ocpp server started and connected with the client simulator
I want to check which function I need to implement for the schedule charging. i.e. to instruct the connect CP to start charging on a predefined time (e.g. Monday 11:30pm - 5am next day) stored in server and start charge remotely from the server side's charging schedule?
Thanks

There are two main methods you can consider:

Send RemoteStartTransaction & RemoteStopTransaction from the CS to the CP at the scheduled time.
Send the scheduling information from the CS as a SetChargingProfile.

Here is an example of the SetChargingProfile:(create for GPT)
import datetime
from ocpp.v16 import call
from ocpp.v16.enums import ChargingProfileKindType, ChargingProfilePurposeType, ChargingRateUnitType

# Create the charging profile with the specified parameters
charging_profile = {
    "chargingProfileId": 1,
    "stackLevel": 0,
    "chargingProfilePurpose": ChargingProfilePurposeType.TxDefaultProfile,
    "chargingProfileKind": ChargingProfileKindType.Absolute,
    "chargingSchedule": {
        "startSchedule": "2024-07-01T10:00:00.000Z",
        "chargingRateUnit": ChargingRateUnitType.A,
        "chargingSchedulePeriod": [
            {"startPeriod": 0, "limit": 16, "numberPhases": 3},
            {"startPeriod": 3600, "limit": 0, "numberPhases": 3}  # 1 hour
        ]
    }
}

# Create the SetChargingProfile message
set_charging_profile = call.SetChargingProfile(
    connector_id=1,  # Adjust according to your CP configuration
    cs_charging_profiles=charging_profile
)

# Send the message to the CP
await charge_point.send(set_charging_profile)

Thanks Yoshida. It is very helpful.
Just one more question as for the SetChargingProfile method, I understand the start time need to be a full Date + Time.
Say if I need that schedule happening every Monday. Whether I need to pre-set all the (or multiple) Monday dates in the profile and send to CP or it need to be set one by one (e.g. after the 1st Monday section finished, then use my server to send the 2nd Monday date and time to the CP?)

There's no need to do that.
SetChargingProfile also has a recurring option (recurrencyKind). You should make use of that.
You should also be able to adjust the start time by using ChargingProfileKindType.
import datetime
from ocpp.v16 import call
from ocpp.v16.enums import ChargingProfileKindType, ChargingProfilePurposeType, RecurrencyKindType, ChargingRateUnitType

# Define the start time for every Monday at 9:00 AM
# Note: This time is in UTC
start_time = datetime.datetime(2024, 7, 1, 9, 0)  # Monday 9:00 AM UTC

# Create the charging profile
charging_profile = {
    "chargingProfileId": 1,
    "stackLevel": 0,
    "chargingProfilePurpose": ChargingProfilePurposeType.TxDefaultProfile,
    "chargingProfileKind": ChargingProfileKindType.Absolute,
    "recurrencyKind": RecurrencyKindType.Weekly,
    "validFrom": start_time.isoformat(),
    "chargingSchedule": {
        "startSchedule": start_time.isoformat(),
        "chargingRateUnit": ChargingRateUnitType.W,  # or ChargingRateUnitType.A depending on your needs
        "chargingSchedulePeriod": [
            {"startPeriod": 0, "limit": 16000, "numberPhases": 3},  # Charging at 16kW
            {"startPeriod": 21600, "limit": 0, "numberPhases": 3}  # Stop charging after 6 hours (6*3600=21600 seconds)
        ]
    }
}

# Create the SetChargingProfile message
set_charging_profile = call.SetChargingProfile(
    connector_id=1,  # Adjust according to your CP configuration
    cs_charging_profiles=charging_profile
)

# Send the message to the CP
await charge_point.send(set_charging_profile)

Thanks Yoshida.
It's great, let me try.


SafeAreaView TW styles not applied

Nativewind is setup correctly as is working on all other react components except SafeAreaView, see code below
import { View, Text, SafeAreaView, TouchableOpacity } from "react-native";

const HomeScreen = () => {
  return (
    <SafeAreaView
      // style={{ backgroundColor: "blue", height: "100%" }}
      className=" bg-blue-500 h-screen"
    >
      <View className="">
        {/* title */}
        <View>
          <Text className="text-center mt-12 text-4xl font-bold">Test</Text>
        </View>
      </View>
    </SafeAreaView>
  );
};
export default HomeScreen;

the TW styles are working on the View and Text components, however the SafeAreaView component/wrrapper they are not working, changing it to just a View works and the TW styles applied work however not as SafeAreaView, it is not an issue with safeareaview as you can see the commented out native inline styles, these work on the safeareaview.
Here are some setup information
"tailwindcss": "^3.3.2"
"nativewind": "4.0.11",
"expo": "^49.0.0",

see two images for before and after appying the SafeAreaView the bg is removed back to white

https://github.com/marklawlor/nativewind/commit/07386292cef8f600cd1e8745d09135467488d7fe
Apparently SafeAreaView will be supported in a future release.

Fantastic just seen the push after this was posted, Appreiciate the work @marklawlor

I am still facing this exact same issue. The SafeAreaView can be styled with native styling using the style prop but the nativewind's classes aren't working.
I am currently using:
    "nativewind": "^4.0.36",
    "tailwindcss": "^3.4.1" ,
    "expo": "~50.0.13"

I am still facing this exact same issue. The SafeAreaView can be styled with native styling using the style prop but the nativewind's classes aren't working. Edit: I am facing this issue when rendering the SafeAreaView in Expo's Tab navigation. It's working as expected in the normal Stack navigation.
I am currently using:
    "nativewind": "^4.0.36",
    "tailwindcss": "^3.4.1" ,
    "expo": "~50.0.13"

I'm facing the same problem with TouchableOpacity.

    "nativewind": "4.0.1",
    "tailwindcss": "^3.4.3" ,
    "expo": "~50.0.14"

I am still facing this exact same issue. The SafeAreaView can be styled with native styling using the style prop but the nativewind's classes aren't working. Edit: I am facing this issue when rendering the SafeAreaView in Expo's Tab navigation. It's working as expected in the normal Stack navigation.
I am currently using:
    "nativewind": "^4.0.36",
    "tailwindcss": "^3.4.1" ,
    "expo": "~50.0.13"

I'm facing the same problem with TouchableOpacity.

    "nativewind": "4.0.1",
    "tailwindcss": "^3.4.3" ,
    "expo": "~50.0.14"

@pedrohamarques try upgrading nativewind to version 4.0.36

Why is this closed? Its still not working

I am having this same issue. Whats really weird to me is that it seems to be working fine in some cases. Check out this Youtube video. I know that I configured Nativewind/Tailwindcss correct but Im still having issues.

This issues should be opened as it has not been fixed for the safeAreaView styling

@Klerith thats not even a suggestion.
The real suggestion is to just use style={{}}

Here is what i did as a walk around
import type { SafeAreaViewProps } from "react-native-safe-area-context";
import { SafeAreaView as RNSafeAreaView } from "react-native-safe-area-context";

import { useThemeConfig } from "@/core/hooks/use-theme-config";

import colors from "../colors";

export const SafeAreaView = ({ children, ...props }: SafeAreaViewProps) => {
  const theme = useThemeConfig();
  return (
    <RNSafeAreaView
      // eslint-disable-next-line react-native/no-inline-styles
      style={{
        backgroundColor: theme.dark ? colors.blue.DEFAULT : colors.white,
        flex: 1,
      }}
      {...props}
    >
      {children}
    </RNSafeAreaView>
  );
};

My use case was around adding inline styles for dark and light mode... But the key thing here is to make it reuseable. I don't think you want to add too many styles to a SafeAreaView than flexing it and adding colors.

    "expo": "~51.0.36",
    "nativewind": "4.1.10",
    "tailwindcss": "^3.4.13"

Similar issue with nativewind 4.1.10

Just add
import { cssInterop } from "nativewind";

cssInterop(SafeAreaView, { className: "style" });

In the root layout in the meantime


[ALLUXIO - 2799] Use precondition check chaining in LineageInfo

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/14416/
Test PASSed.

alluxio-bot, check this please

@nanshoudeooo could you sign the contribution license agreement?
also can you resolve the merge conflict?

@nanshoudeooo  feel free to reopen this PR after you sign the CLA


[BottomNavigation] use theme.spacing.unit

Same as #10268

@cherniavskii theme.spacing.unit isn't meant to be used everywhere. Notice that it has a performance overhead. The idea is to use it for increasing harmony & balance with symmetry. Using non integer factor start to defeat the purpose.

to use it for increasing harmony & balance with symmetry

Good point.

it has a performance overhead

Why? Does getting properties from theme object hit the performance?

Why? Does getting properties from theme object hit the performance?

@cherniavskii Pushing this approach forward will lead to N new integer multiplications and gzip might not be very efficient at compressing the expression. Having said that. It's unclear if it's significant or not.
More importantly, let's try to use for enforcing symmetry.

@oliviertassinari I see, indeed gzip compression may be an issue in this case.


Is there way to compare R and Python implementations?

Hi all,
It all started as I ported a model from R to Python and noticed performance worsened. I tried then to compare a simplistic model on a toy data to exclude all sources of incomparability. Without avail: Python and R versions of Xgboost produce slightly different models, it is noticeable at the training time. What is more strange, if seed is not set, R implementation trains model differently every run. Python implementation does not depend on seed.
Both are current releases installed via CRAN and pip. This behavior remains the same on Ubuntu and Windows. Can I still run R and Python Xgboost in a comparable way?

this is due to random seed. Normally you should not relies on random seed to get good perfmance, since this can mean overfitting. In other sense, all bindings are fully compatible


Add new section for online learning resources

IOT School - https://iotschool.microsoft.com/
AI School - https://aischool.microsoft.com/
AI Labs - https://www.ailab.microsoft.com/
MVA - https://mva.microsoft.com/
Channel9 - https://channel9.msdn.com/

@leestott
Hello!
Can I try to solve this issue?
Can I put links in this section or create another? // https://github.com/Microsoft/computerscience#content-from-other-sources

Ping @justgar


Fix params parsing when path is using Google rest api guidelines

After upgrading to 5.25 our API crashed during startup.
After investigation problem was detected in OperationProcessor.ParamCreationContext
Fixed it to allow routes named using google rest api guidelines
/api/{id}:deactivate

Thanks for the PR, greatly appreciate the addition of tests :-)
But, the regex didn't work correctly for route patterns with multiple constraints such as this:
/api/{id:min(1):max(5)}:deactivate

So I got rid of the regex and added another Where() clause to filter candidates.
Seems to be working correctly now.
Could you give it another look and if everything seems ok, I will merge.
Thanks!

@KateyBee sorry for that miss, honestly i didn't even knew that that type of constraint is even possible 😺

looks good to me.
thanks @idormenco for the PR 🙏


Z Wave force_update support

Description:
This change set enables force_update as part of the zwave customization on a per device basis.
Related issue (if applicable): fixes #1938
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#1938
Example entry for configuration.yaml (if applicable):
zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/hass/src/python-openzwave/openzwave/config
  polling_interval: 60000
  customize:
    binary_sensor.binary_sensor_entity_id:
      polling_intensity: 1
      force_update: True
   switch.switch_entity_id:
     polling_intensity: 5
     # force_update: Defaults to False
  lock.lock_entity_id:
    force_update: False

In the yaml above, only the binary_sensor with the stated entity ID should have force_update enabled on it. The others should respond as they do today and only update on actual changes.
Checklist:
If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

Hi @tony-schellenberg,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

We should not make this globally configurable.
force_update should be true when the measurement that is coming in is a new measurement taken at that point in time. It's only relevant for devices that we want to plot with line charts, have a unit.

My intent is to make this customizable on a per zwave entity basis (not apply globally to all zwave devices unless individually customized to do so). I've expanded the sample yaml in the description to show this. The configuration is optional and defaults to False which I believe will maintain the existing behavior you describe.
Have I understood your comment/concern correctly?
As an aside, the use case I am working towards supporting is detection of zwave devices that are having problems. My particular device wakes up periodically and will respond to pending requests at that time. However, if the state is unchanged I can't detect that the device has sent replies to the pending requests. So, if a state hasn't changed for 5 days I don't have a good idea if it's because the state simply hasn't changed or if the device is not waking up and checking in properly.

@turbokongen FYI
This would be indeed useful for rarely-awake devices.
It is useful not only for charts but for automation based on last-updated timestamp.
Maybe we should even make this default to true for devices with battery_level attributes.

I like the idea of this, to update the state on wakeup.
I agree to make it default to True on devices having the battery_level attribute. :+1:

So for a first pass, let's enable force_update for devices with battery_level attribute and after that we can judge if we still need to be able to overwrite this.
On a side note, I do not like that Z-Wave has a customize section that is actually used on a per device config instead of customizing what attributes get written to the state machine (like the homeassistant/customize section).

I'll try to find some time to work on this in the next few days and see what I can do.
I can switch this to take the state from the homeassistant/customize section if that makes this more acceptable as a configurable parameter. Please let me know your thoughts on that.
Overall, I still have use cases for wanting to monitor all polled devices (battery and line). For my immediate needs, the devices are all battery operated. Longer term, I'm working on some ideas that would need this behavior for line powered devices.

@balloob @andrey-git @turbokongen
I spent a bit more time thinking about this overnight and wanted to make sure that this won't have some unintended negative side effects (especially since it would be on for battery devices).
Looking at this PR, force update sets both the last_updated and last_changed times. Will this have negative effects on things like state duration triggers and conditions?
Related, are there other known use cases for last_changed and last_updated in templates that would be broken by making the proposed changes?

An alternative would be to add a state attribute that you update every time you send an update. Then last_updated will change but not last_changed. Eg you can add an attribute called heartbeat where you increase a count for every update.

We should not use the homeassistant/customize section. Z-Wave config has to remain in Z-Wave config section.
State duration triggers will work just fine, as they check the state value, not last_changed.
@tony-schellenberg wrote:

I don't currently have the line powered modules so I'm not sure how they behave but I am interested in getting the timestamps updated even if the state hasn't changed for them too.

Let's not do it this time. Maybe in the future. We first have to see how this works out. So like I said before:

So for a first pass, let's enable force_update for devices with battery_level attribute and after that we can judge if we still need to be able to overwrite this.

Closing this in favor of https://github.com/home-assistant/home-assistant/pull/5844


Update npm package

Hi,
I would like to use your plugin. Could you publish the lastest version in npm, please?
Thanks,

you can install it from github npm install [--save] nnattawat/flip
flip on npmjs is another module. Pls change your readme


http: turning up H2 websocket support

The main difference between what we had and official nghttp2 support is lack of support for upgrade-with-bodies (on request or response path).  Adjusted header munging, tests, and docs accordingly.
Risk Level: Low (changes code on a "hidden" code path)
Testing: updated tests, new unit tests
Docs Changes: updated
Release Notes: noted H2 websocket support
Fixes #1630

@rshriram or @moderation may want to take a look too?

Huh, https://github.com/envoyproxy/envoy/pull/4761 landed, it caused a new docker image, https://hub.docker.com/r/envoyproxy/envoy/tags/, this should Just Work (TM) but something about the old nghttp2 library is getting cached somewhere.  I'll see if I can sort it out tomorrow.

@alyssawilk you need to update the CI image in .circleci/config.yml:
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -4,7 +4,7 @@ executors:
   ubuntu-build:
     description: "A regular build executor based on ubuntu image"
     docker:
-      - image: envoyproxy/envoy-build:faea2a2ebc397b7a3a5e3c877ceaefc5cf4daf25
+      - image: envoyproxy/envoy-build:7971d426155c3a9cc3e2b99bc7802b6b22df7a09
     resource_class: xlarge
     working_directory: /source

This is great!! don't care much about being able to support upgrades on requests with bodies.

Oh thanks Piotr!  I'd remembered it was latched somewhere and was failing to find it.  That plus the proper hash (I was grabbing envoyproxy/envoy not envoyproxy/envoy-build hashes) did it.

Ping!


Update README.md with spelling corrections

Spelling corrections made to README.md, as per document instructions.

Nice work!

@Br3W7h1S feel free to add some new spelling errors for the next person 👍

In a new PR, of course. Now that this one is merged you'd have to do a new one. So update your fork using fetch from upstream and then add whatever you want, if you so choose.

In a new PR, of course. Now that this one is merged you'd have to do a new one. So update your fork using fetch from upstream and then add whatever you want, if you so choose.

I will give this a try!  Thanks! :D