createMany should return the created records

Initially brought up here: https://github.com/prisma/prisma/issues/4998#issuecomment-787206842
Problem
The fact that the createMany API does not return the created records (which should be possible for Postgres) makes it difficult/impossible to use in some circumstances, meaning we must fall back to raw SQL. Here's an example.
Let's say I have these two tables
CREATE TABLE IF NOT EXISTS post (
  "id" SERIAL PRIMARY KEY,
  ...
);

CREATE TABLE IF NOT EXISTS comment (
  "id" SERIAL PRIMARY KEY,
  "postId" INTEGER NOT NULL REFERENCES post ("id") ON DELETE CASCADE,
  ...
);

Let's say I want to create many posts and many comments. The data to be created could be represented like so: Array<{post: PostData, comments: Array<CommentData>}>. If createMany returned the created data, I could do something like this:
const inputs: Array<{post: PostData, comments: Array<CommentData>}> = [...];
const posts = prisma.post.createMany({data: [...]});
const commentCreateData = inputs.map((input, index) => input.comments.map((commentData) => ...))).flat();
prisma.comment.createMany({data: commentCreateData});

However, since createMany does not return the created data, it is difficult to create many posts and then create many comments linked to those posts in an efficient manner. The remaining options are to create records one-by-one or use raw SQL. Using a combination of createMany and findMany is possible if you manually specify IDs, but does not work if you rely on Postgres (or some other DB) to generate IDs by default.
Suggested solution
createMany should return an array of created records (like how create returns the single created record).
Alternatives

Use create (inefficient if creating many records)
Use raw SQL (efficient but inconvenient)
Use createMany + findMany (only works if you manually specify IDs, and also less efficient than if createMany returned created records)

Additional context
Personally, I've used raw SQL as a workaround since it's the most efficient alternative.

This would be great to have.
From what I've gathered, Postgres, SQLite and MariaDB support INSERT RETURNING which could be used for this, but MySQL does not.
I suppose this would open the door to also supporting nested writes inside createMany

great if have this feature

+1 would love support for this.

Yeah, it will great if we support one flag that will return the newly created data from createMany. Same for the deleteMany too

return await this.prisma.$transaction(
   users.map((user) => prisma.user.create({ data: userCreateData })),
);

Currently using this type of abstraction for handling this. If createMany would return the array of entities, that would be great.

Are there any plans to include this feature in the future? I have checked the roadmap, but it seems that there isn't.

Yeah we could really make use of this feature, are there any updates? Thanks!

Hey there. Unfortunately no plans yet because not all natively databases support this and we're not quite at the stage where we can adjust root-level operations based on the connector.
For now, we recommend the suggestion that @GauravRajSharma mentioned. Please let me know if you run into any problems with that approach and I can try to find alternatives for you.

+1

+1

+1 Why people would not want such behavior? 😥

I cannot understand why a such common use case has no solution yet, the developers keep adding things to the lib while it can't handle simple things, It makes me sad about software development, I think simplicity and performance should  be the the direction of every framework, and have to add records one by one or use raw SQL to it simply nullify the usage of the tool.

@hlspablo Yes, it is a very common case! However, Prisma has already set a roadmap, and they do not seem to decline from their goals. Basic features like this and soft delete are by default included in TypeORM. It is sad that they do not try to provide at least the fundamental features of their competition.

otherwise we have to query the DB again to get the data we added with the correct Ids. Imagine if you have multiple records.

If the ID is generated via trigger rather than explicitly specified by client, not being able to use RETURNING is pretty much a deal-breaker.

This is absolutely necessary.

@andrewicarlson Following our chat, this is the issue with the <create/update/delete>Many not returning the models but the count only.

Hey there. Unfortunately no plans yet because not all natively databases support this and we're not quite at the stage where we can make fine-grain adjustments to our APIs depending on the database.
For now, we recommend the suggestion that @GauravRajSharma mentioned. Please let me know if you run into any problems with that approach and we can try to find alternatives for you.

I think that's a bad project decision to keep adding support to new databases while the ORM can't handle so primitive things like this, we are doing weirds things to compensate this decisions and not hurt performance, if we have to make RAW queries for ALMOST anything that is not a simple CRUD, JOIN, or GROUP, whats the real point of an ORM? switch from databases in one line of code?

to complement my comment, I think that returning items array as part of result for supported databases and empty for non supported is better than returning anything, and that wouldn't be a breaking change.
something like {
count: number;
items: []
}

This is one of the basic features that ORM should support. Voting for consideration
+1

This is an absolutely basic featue for bulk requests in nearly every application, where you need to insert many data. I am working now in 2 big projects where performance and bulk requests are really important.  When i insert 1000 records, i need feedback what records i created, not just the count. Maybe an includes flag in create many would be great here. Then you could decide what data should be returned. Same as for Nested create many operation Feature. These features are now more than one year open as well as the nested createMany feature. Is it still on the priority list? I like prisma and love how much effort  the devs put into this project. But sometimes i get the impression that such basic  features get a to low priorization. I know that there are many tasks to do,  but if it takes to long, there are and will be other framework alternatives, which handle bulks much better. Would like to see this in the near future. It would be a waste of potential for this amazing project.
So thanks for all your time you spent in here 🙌
Best regards
Andreas

@andreasvh-conceto  this remember me react native few months ago where some issues had 4 year birthday, fortunately things there are pretty good now, most of them were fixed, lets hope prisma project get the same attention to important matters like this one.
We have one year birthday to the simplest use case of an ORM, let see what happens. Unfortunately, for JS, there is no many good ORM options around.

+1

+1

+1

+1

+1.
Btw solutions could be:

Returning arg and if is not supported by db throw an error.
A different method createManyAndReturn (I'm so bad giving names) (Specify that's only available for certain dbs)

I need exact this feature nowadays. It would be great if it is possible.

Come on man, this is soo basic

Hi there,
I'm needing to use this as well for the same reasons the original poster mentioned, so attempting to use queryRaw. Having some difficulties though, and I can't see what I'm doing wrong:
Here's how I'm generating my values:
const values = rows.map((row) => `('${row.status}', 'null')`);

I'm then attempting the insert like this:
await prisma.$queryRaw`INSERT INTO quotes.shipments (status, errors) VALUES ${values} RETURNING *`;

The values actually coming back from my above function work – if I paste the output into the above Prisma insert function, or use directly inside PG, it inserts fine.
But Prisma gives me the following back:
PrismaClientKnownRequestError:
Invalid `prisma.$queryRaw()` invocation:

Raw query failed. Code: `42601`. Message: `db error: ERROR: syntax error at or near "$1"`

I'm assuming it's an issue related to what's documented here: https://www.prisma.io/docs/concepts/components/prisma-client/raw-database-access#considerations
But I'm not sure what I'm actually doing wrong, or if that's even the issue.
Any ideas?

@sebpowell Can you please try this following:
const values = rows.map((row) => `('${row.status}', 'null')`);
  await prisma.$queryRaw`INSERT INTO quotes.shipments (status, errors) VALUES ${Prisma.join(
    values
  )} RETURNING *`;

+1 really need this

adding to the bump list.... +1

+1 on this, very helpful you need to create records on multiple related tables and connect them

@janpio should this have the topic: RETURNING?

+1 for this feature

+1

+1

+1

+1
Please reconsider marking this one as a top priority.
We would all be very helped.
Thank you for creating Prisma!

+1 this is a MUST feature to be in ORMs

+1

+1

+1

Another comment, another vote to prioritize this feature.
Also, stop marking comments as disruptive or off-topic. It is very much ON topic to consistently bump this thread and apply pressure for a feature that is strongly desired by users. If you don't like it, perhaps don't take 1.5+ years and counting to address the issue??

Hey @franwollang, thanks a lot for your feedback!
We're appreciating all the comments and the wish for us to implement this feature. Unfortunately, our Product team hasn't been able to prioritize this feature yet. As @GauravRajSharma has pointed out above, there's a workaround that can be used for this today:
return await this.prisma.$transaction(
   users.map((user) => prisma.user.create({ data: userCreateData })),
);

Our Product team is constantly re-evaluating the features on the roadmap and all the comments here help us prioritize! However, at a certain point we reserve the right to hide comments to keep the discussion in the issue clear. Hiding (instead of deleting) comments has the benefit that they're still visible in the timeline so people can find them if needed.
We hope that this addresses your concerns, thanks again for sharing your thought 🙏

For those complaining about this issue not being addressed: reminder that this is free software. The authors owe you nothing. Maybe instead of complaining you should contribute and open a PR to solve this issue yourself as a means of saying thank you for their hard work.
Thanks you @nikolasburk and team for making such an awesome framework and sharing it for free!

@ky1ejs That's not really true for Prisma. See https://github.com/prisma/prisma-engines/blob/main/CONTRIBUTING.md#external-contributions:

External Contributions
Most of the development of Prisma Engines is done by employees of Prisma. We welcome external contributions, but need to balance that with the direction set in our company roadmap. Before attempting to implement any large feature we recommend chatting with us first through Slack, or opening an issue first.

I asked once if I can contribute a feature that's not on the roadmap, but Prisma team didn't response.

Hey @franzwollang, thanks a lot for your feedback!
We're appreciating all the comments and the wish for us to implement this feature. Unfortunately, our Product team hasn't been able to prioritize this feature yet. As @GauravRajSharma has pointed out above, there's a workaround that can be used for this today:
return await this.prisma.$transaction(
   users.map((user) => prisma.user.create({ data: userCreateData })),
);

Our Product team is constantly re-evaluating the features on the roadmap and all the comments here help us prioritize! However, at a certain point we reserve the right to hide comments to keep the discussion in the issue clear. Hiding (instead of deleting) comments has the benefit that they're still visible in the timeline so people can find them if needed.
We hope that this addresses your concerns, thanks again for sharing your thought 🙏

This workaround isn't really a workaround at all.
There are performance implications to making multiple createOne calls and to say it is significantly slower than a bulk insert is an understatement. This kind of workaround should not ever be used in production. Not to mention wrapping possibly 1000+ createOne calls in a transaction...
I hope the product team recognizes the importance of this feature. As many others have mentioned this is a basic feature that competitors like TypeORM already has.

Hey @franzwollang, thanks a lot for your feedback!
We're appreciating all the comments and the wish for us to implement this feature. Unfortunately, our Product team hasn't been able to prioritize this feature yet. As @GauravRajSharma has pointed out above, there's a workaround that can be used for this today:
return await this.prisma.$transaction(
   users.map((user) => prisma.user.create({ data: userCreateData })),
);

Our Product team is constantly re-evaluating the features on the roadmap and all the comments here help us prioritize! However, at a certain point we reserve the right to hide comments to keep the discussion in the issue clear. Hiding (instead of deleting) comments has the benefit that they're still visible in the timeline so people can find them if needed.
We hope that this addresses your concerns, thanks again for sharing your thought 🙏

This workaround isn't really a workaround at all.
There are performance implications to making multiple createOne calls and to say it is significantly slower than a bulk insert is an understatement. This kind of workaround should not ever be used in production. Not to mention wrapping possibly 1000+ createOne calls in a transaction...
I hope the product team recognizes the importance of this feature. As many others have mentioned this is a basic feature that competitors like TypeORM already has.

Yes. This is a weak workaround that doesn't address any performance. Hopefully the prisma team does prioritize this feature.
@nikolasburk suggesting this might not be what the consumer of prisma wants.

@yume-chen thanks for correcting me, makes total sense 👍🏼 agreed!

+1

+++1

+1

+1

Joining the choir here. We have several points in our codebase where we need to perform a bulk-import of information from an external service. Requiring us to either write raw SQL or incur a performance penalty is a pretty subpar experience and makes it harder for me to keep folks in the company onboard with our migration to Prisma from Sequelize (which IMO is a worse designed tool, but has some key features like this, the ability to represent Postgres Bigint columns as numbers, and soft-delete that are making the migration painful).
I'm optimistic that the fact that the roadmap currently inclues some postgres-specific features like PostGIS means that the team would be open to implementing this for a subset of target DB backends in the near future.
Until then, though, has anyone profiled the performance difference between performing a SQL create-many-returning call vs. doing the recommended workaround of many create calls in a transaction? For our internal guidance on when to stop using the workaround, I need to know how much slower it is (e.g. does it scale linearly by row or is there some runtime savings from the transaction). I can do this myself if no one else has investigated it yet.

It would be really helpful to get this feature prioritized.

joining the request for prioritized.

+1
pon., 6 lut 2023, 13:23 użytkownik mhevron @.***>
napisał:

joining the request for prioritized.
—
Reply to this email directly, view it on GitHub
https://github.com/prisma/prisma/issues/8131#issuecomment-1418997689,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AARJ4R6ZUF3X7665QIKSOD3WWDUK7ANCNFSM475TDTYA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

+1

+1

+1

At this point, all the time spent marking comments as abuse could have been used implementing this much requested and loved feature from 2021!
(For those doubting, this is meant as a lighthearted comment, we still love you, Prisma team)

Unfortunately, I have to mark them as abuse or I will have 10x more tomorrow (and even more after a week, month, year...) - and then everyone working at Prisma gets even more notifications each day for issues where nothing really changed and no new useful information is available. And yes, if we did not have the notifications stealing our time, and we would not have to mark them as abuse, we would have a tiny bit more time to work on features. (The alternative btw is that we start ignoring issues and comments completely - also not a great solution I fear.)

I came up with this solution, it is fast as it's still a bulk insert. Still using prisma.
`function bulkInsertItems(items: item[]) {
const result = await client.item.createMany({
data: items
})
const idResult = await client.$queryRaw<{ id: BigInt }[]>`SELECT LAST_INSERT_ID() as id`
const firstInsertedId = Number(idResult[0].id)
return Array.from({ length: result.count }, (_, i) => firstInsertedId + i)

}`

I came up with this solution in my code. It's fast as it's still a bulk insert and it's still using prisma.
function bulkInsertItems(items: item[]) {
    const result = await client.item.createMany({
        data: items
    })

    const idResult = await client.$queryRaw<{ id: BigInt }[]>`SELECT LAST_INSERT_ID() as id`
    const firstInsertedId = Number(idResult[0].id)
    return Array.from({ length: result.count }, (_, i) => firstInsertedId + i)
}

Unfortunately, I have to mark them as abuse or I will have 10x more tomorrow (and even more after a week, month, year...) - and then everyone working at Prisma gets even more notifications each day for issues where nothing really changed and no new useful information is available. And yes, if we did not have the notifications stealing our time, and we would not have to mark them as abuse, we would have a tiny bit more time to work on features. (The alternative btw is that we start ignoring issues and comments completely - also not a great solution I fear.)

@janpio
Just a suggestion, if it's not too much more work on your plate perhaps it could help if the Prisma team maintained a list of known and most-requested features with some basic reasons why the features are not currently planned (maybe with an upvote feature too that the communicate can vote on). I think doing so will do a better job of communicating with the community on some of the difficulties implementing some features, why this feature isn't currently a priority, etc., and acknowledge that the community is being heard (not asserting that you guys do a bad job at communicating at all, you do a wonderful job of doing so). Reading the thread it seems many people feel the need to keep requesting and bumping this thread because it's been three years since this thread was made and it's not on the roadmap.

The reason why something that exists as a popular issue here is not on the roadmap is always the same: Something else is currently a higher priority, and we do not have the capacity to do more than what we are currently working on. So I could only list all valuable issues and copy/paste the same text next to all of them (There is really almost never another reason (that I could communicate)) - that would be frustrating as well.
The upvote feature exists already: Leave a 👍 on the issue here. We do see these and take them into account when we do have time to re-prioritize other things.

+1 waiting for this as well

I was able to get this working with Prismas new preview feature clientExtensions 🎉. My extension assumes you are using Postgres and that you name your model in PascalCase and that the primary key is always named id and are bigint/bigserial as the type of the id field. However, that should be quite easy for you to adapt this code to your setting.

In your schema.prisma-file add, the clientExtensions to the previewFeatures:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["clientExtensions"]
}

In the file where you create your prisma-client (i.e where you are doing new PrismaClient()), add this piece of code:

import { snakeCase } from "change-case";

const basePrismaClient = new PrismaClient();

export const prisma = basePrismaClient.$extends({
  name: "createManyAndReturn",
  model: {
    $allModels: {
      async createManyAndReturn<T, A>(
        this: T,
        args: Prisma.Exact<A, Prisma.Args<T, "createMany">>
      ): Promise<Prisma.Result<T, A, "createMany"> & { ids: bigint[] }> {
        const thisAny = this as any;
        const argsAny = args as any;
        const ctx = Prisma.getExtensionContext(this);

        const providedIds: bigint[] = [];

        argsAny.data.forEach((record: any) => {
          if (record.id) {
            providedIds.push(record.id);
          }
        });

        const numberOfRecordsWithoutId =
          argsAny.data.length - providedIds.length;

        const ids = await basePrismaClient.$queryRaw<
          {
            nextval: bigint;
          }[]
        >`
          SELECT nextval(pg_get_serial_sequence(${snakeCase(
            ctx.name
          )},'id')) FROM generate_series(1, ${numberOfRecordsWithoutId}) n
        `;

        const newRecords = argsAny.data.map((record: any, index: number) => ({
          ...record,
          id: record.id ? record.id : ids[index]?.nextval,
        }));

        const result = await thisAny.createMany({
          ...argsAny,
          data: newRecords,
        });

        return {
          ...result,
          ids: [...providedIds, ...ids.map((id) => id.nextval)],
        };
      },
    },
  },
});

@marcus13371337 that really looks amazing, however could something similar be achieved for MySQL? I really prefer not to leave Planetscale 💀

@marcus13371337 thx will give it a try!

My solution for this was to run two calls one after another.
I would store IDs or keys that I am using for both batch operations and call first batch insert and then after it call batch get or rather findMany.
Sample of code I am using:

const userList: User[] = [
// List of users to be inserted
];

// Compute the emailList from the userList by use of the Array.map or similar method. Not showing it here.

const insertCount = prisma.user.createMany({
    data: userList,
});

const usersRegistered = prisma.user.findMany({
  where: {
    email: {in: emailList},
  },
});

This gives me two queries instead of n queries, n being the number of inserts in bulk operation. So a bit safer for my use case than the transaction solution.
Potentially big ones but I understand the scope of my feature so it is acceptable for me, your mileage might vary.

We have some tables with a composite primary key, so the current workaround requires us to build a where filter which essentially ANDs all of the composite key values together and then ORs that expression with the other record keys being inserted. While ugly, this "works" until we insert 32,767 / <# of columns in composite primary key> rows (32,767 is the maximum number of bind parameters supported by PostgreSQL within one query). To get around that, we've had to run run multiple queries to fetch the records...
Our solution looks something like this:
        // To get around PG's bind param limit, we'll need to chunk the query
        // Divide the limit by 3 (and add some breathing room) since we're filtering by 3 parameters for each element created
        // The resulting query will look something like:
        //   SELECT * FROM "myTable" WHERE((primaryKeyColumnOne = $1 AND primaryKeyColumnTwo = $2 AND primaryKeyColumnThree = $3) OR (primaryKeyColumnOne = $4 AND primaryKeyColumnTwo = $5 AND primaryKeyColumnThree = $6) OR ...)
        const result = _.orderBy(
            (
                await Bluebird.map(
                    _.chunk(recordsToInsert, 32767 / 3 - 100),
                    (rowsToGet) => {
                        return this.prisma.myTable.findMany({
                            where: {
                                OR: rowsToGet.map((row) => {
                                    return {
                                        primaryKeyColumnOne: row.primaryKeyColumnOne,
                                        primaryKeyColumnTwo: row.primaryKeyColumnTwo,
                                        primaryKeyColumnThree: row.primaryKeyColumnThree
                                    };
                                })
                            }
                        });
                    },
                    // We don't want to overload the prisma connections / queue in a way that could delay other queries
                    { concurrency: 4 }
                )
            ).flat(),
            'createdAt',
            'desc'
        );

        return result;

Would really like to see support for RETURNING * as others have mentioned in this thread 😢

Would also really like to see this implemented! Not having it really blocks some middleware functionality.

Just ran into this issue as well, would love to see this as a new feature.
Here is my work around:
`const newTags = await Promise.all(
newTagNames.map((name: string) =>
db.tag.create({
data: {
name,
},
})
)
);
`

+1

@matthewmueller Why not just make it seperate for the databases that do support it? For example on Databases where it's not supported keep the current batch type. But on databases where this is supported BatchType could extended to
export type BatchPayloadResults extends BatchPayload = {
  results: [...]
}

so users get
{
  count: 30,
  results: [....]
}

Going on 2 years here, hopefully we can get this basic feature one day instead of going around the api

Yeah just hit the wall with that one also. Hope this gets implemented. Now off I go to create a workaround for pg  ehh

The best Workaround I fpund so far is using a transaction like this.
const inserts = req.body.map((item) =>
    prisma.subjectslists.create({
      data: {
        color,
        title,
        user_id,
      },
    })
  );

  // using transaction to workaround createMany not returning the results
  // https://github.com/prisma/prisma/issues/8131
  const subjects = await prisma.$transaction(inserts));

Only downside is it will do it in multiple queries instead of one.

Ok now its time to bring this issue to life again. Officially prisma are considering using RETURNING to optimize there queries from the latest release notes This is the pefect time to go step further and add least enable this feature for postgres and cockroach.
@ChristophP found an workaround, but still we dont have any official support returning data from the created records.
What i mean are exactly these cases, where i need to add multiple records and directly want to have the id or anything else from this table back. Look at the following code (5.1.1), where i add more than one record (in my productive scenario i have over 1000):
const result = await prisma.communicationParticipant.createMany({
        data: [
          { created_by: "SYSTEM", name: "foo" },
          { created_by: "SYSTEM", name: "bar" },
        ],
        skipDuplicates: true,
       include: { id: true, name: true}. /// something which would be a good move especially because you can use returning also for create bulk operations, but its not implemented yet
 });

console.log(result) still returns { count: 2 }. But RETURNING would allow extending this API in a better way (i.e. with the include property above) in order to return directly the id or other columns of this table. Otherwise iam forced to perform a findMany again, just to find out, which ids are created. create one by one is not an option. The interfaces we implement must be performant and because of this missing feature we still perform prisma.queryRaw and the sql like this:
await prisma.queryRaw`Insert into communication_participant(created_by, name)
values
('SYSTEM','foo'),
('SYSTEM','bar'),
(...)
Returning id, name;`;

If you create 1000 records in one go with RETURNING id,name, we increase performance a lot, because we only have to send data one time to the database and directly get our desired results back. The same you could also adjust to updateMany operation. I mentioned this last year and i follow every minor update - but iam still waiting for this feature and idea from the community. And when i read this comment history iam defently not the only one.  If major relase 5 stands for performance, it is now the time to bring features like this in. Otherwise prisma.queryRaw is still my best friend for createMany and updateMany operations.
Is there anything in the planning? @janpio  / Prisma Team :)
And of course thanks for the new release, i have hope again bringing in features like this.
Best regards
Andreas

Please do this. Thank you.

+1  just send a reminder to this issue

I have a use case where I just need the newly created items and not the all items in the table that are linked to a table using only an ID key. There's no way to determine the newly created records. Returning the newly created items should solve my concern.

I'm leaving an alternative work around that works  for tables with not only auto-incremented ID but time-sortable column and  databases without RETURNING clause (like MySQL)
This assumes that

tables have creation-time sortable column (like createdBy, CUID, ULID, auto-incremented ID)

and indices for that column are highly recommended for performance.

transaction isolation level needs REPEATABLE_READ or more

WARN: MySQL's default is REPEATABLE_READ, but many other databases's default  are lower than it

prisma.$transaction(
    async (prisma) => {
        const last = await prisma.someResource.findFirst({ orderBy: { createdBy: 'desc' } }) // or { orderBy: {id: 'desc'} }

        await prisma.someResource.createMany({ data: batchData })

        return prisma.leadProfile.findMany({ ...(last && { where: { createdBy: { gt: last.createdBy} } }) }) // or { id: { gt: last.id } }
    },
    // { isolationLevel: Prisma.TransactionIsolationLevel.RepeatableRead }  // if needed
)

@bigen1925 that solution will not scale well. You might get other records created by a concurrent insert back

Thank you so much, @marcus13371337 !
I have misunderstood REPEATABLE_READ.
I updated the code 😢

Yeah, would be great to have this. Prisma did a lot of query optimizations in the past releases, I was hoping this would come as part of that effort.

Really had to sign into my github just now in order to echo everyone else in saying it's entirely pathetic that the library does not support this extremely basic feature

We have a use case where we are needing to perform numerous operations as part of a single transaction - the final two operation involve an updateMany - where essentially a nested write to a separate audit table needs to take place for each record updated (another feature unsupported by Prisma, though that is more understandable).  We are first doing an updateMany, followed now by a createMany.  There is a default id generated during the createMany that we must have access to in order to stream this data to another system.  This would be trivial to accomplish via raw SQL and now I have spent a considerable amount of time trying to implement a work around.
Using ChristophP's workaround is possible, but unwieldy as there are already FOUR other operations taking place during the transaction - I would need to slice the resulting array to grab the relevant results.  overall just very ugly.

Stepping into new year without this is painful

@matthewmueller any update?

I really hope this feature gets implemented. While it may not be possible for ALL databases, that doesn't change how useful this feature would be.

died waiting for prisma features

Damn.

3 years and nothing yet? Just saw this, because I used createMany now and it return the count only, that's odd. 😕

Can someone from @prisma tell us why this is not a priority?

Planning on using competitor ORM's for future projects due to this issue and lack of response from Prisma team on this.

I am also waiting for this feature @prisma. This issue has been open for 2.5 years and it's really useful.

For databases like postgres where the returning statement is supported even insert update operations for multiple records are working in a performant way. Currently with raw queries we perform multiple thousands of upsert statements like this and it is a game changer. Other databases, which do not support this could execute a select statement.

@andreasvh-conceto Hello! Could you provide an example for postgres ? a snippet ? Thanks

Hi @Pamavoc ,
this is a possibility for createMany, if you want to return fields from the created records. Just like the same prisma is doing currently for the create, use it for multiple values. Let me illustrate this with prisma code and postgres sql.
const results = await prisma.myTable.createMany({
        data: [
          { created_by: "SYSTEM", name: "foo" },
          { created_by: "SYSTEM", name: "bar" },
        ],
        skipDuplicates: true,
       select: { id: true, name: true}. // something which would be a good move especially because you can use returning also for create bulk operations, but its not implemented yet. It can be the same (nested) syntax prisma use already for queries.  include as a whole could also be a good thing, but having the option to select is often more performant depending on the number of columns. But include is worth it if the user i.e. wants to have the created records
 });

Insert into mytable (created_by, name)
values
('SYSTEM','foo'),
('SYSTEM','bar'),
(...)
ON CONFLICT(name) DO NOTHING. // in case skipDuplicates: true and a unique constraint is defined to name, leave it away if skip dupicate is set to false
Returning id, name;

If you want to go a step further, lets say, you want also directly get records with joined table columns in prisma like defined here:
const results = await prisma.myTable.createMany({
        data: [
          { created_by: "SYSTEM", name: "foo" },
          { created_by: "SYSTEM", name: "bar" },
        ],
        skipDuplicates: true,
       select: { id: true, name: true, my_joined_table: select: {baz: true}}. // here lets say beside the id and name, i want also to have the related column `baz` for a joined table model called `my_joined_table`. Include would also be great if you want to return the whole record with all colums directly, but select can be more performant
 });

, you can do this also in postgres with single CTE query:
WITH cte_insert AS (
          Insert into mytable (created_by, name)
          values
         ('SYSTEM','foo'),
         ('SYSTEM','bar'),
         (...)
         ON CONFLICT(name) DO NOTHING. // in case skipDuplicates: true and a unique constraint is defined to name, leave it away if skip dupicate is set to false
  Returning id, name;
        )
SELECT cte_insert.id, cte_insert.name, my_joined_table.baz JOIN my_joined_table ON cte_insert.id=my_joined_table.id;

Currently we do this in our projects with 1000 of records in a performant way using raw queries.
In general i would say: If a developer is providing include or select in the createMany operation, evaluate it like the way here. If they are not defined, return the count like it is already implemented in prisma.
This would be awesome enable much flexibility! For update statements and i also mean for delete it is the same approach, since you can also use returning for update/(delete) statement. Assuming you want to get the deleted record for a deleteMany prisma query. So createMany, updateMany and deleteMany can be much boosted by this :)
Hope this helps.
Thanks a lot and best regards
Andreas

Would be useful

Still no response 💀💀💀💀

+1

So, when will it be implemented?

Just here to say I also really need this feature.

+1

This would be useful to have :)

Hi @Pamavoc ,
yes of course. This is a possible solution for createMany, if you want to return fields from the created records. Just like the same prisma is doing currently for the create, use it for multiple values. Let me illustrate this with prisma code and postgres sql.
const results = await prisma.mytable.createMany({
        data: [
          { created_by: "SYSTEM", name: "foo" },
          { created_by: "SYSTEM", name: "bar" },
        ],
        skipDuplicates: true,
       select: { id: true, name: true}  // something which would be a good move especially because you can use returning also for create bulk operations, but its not implemented yet. It can be the same (nested) syntax prisma use already for queries.  include as a whole could also be a good thing, but having the option to select is often more performant depending on the number of columns. But include is worth it if the user i.e. wants to have the created records
 });

Insert into mytable (created_by, name)
values
('SYSTEM','foo'),
('SYSTEM','bar'),
(...)
ON CONFLICT(name) DO NOTHING. # in case skipDuplicates: true and a unique constraint is defined to name, leave it away if skip dupicate is set to false
Returning id, name;

If you want to go a step further, lets say, you want also directly get records with joined table columns in prisma like defined here:
const results = await prisma.myTable.createMany({
        data: [
          { created_by: "SYSTEM", name: "foo" },
          { created_by: "SYSTEM", name: "bar" },
        ],
        skipDuplicates: true,
       select: { id: true, name: true, my_joined_table: select: {baz: true}}. //here lets say beside the id and name, i want also to have the related column `baz` for a joined table model called `my_joined_table`. Include would also be great if you want to return the whole record with all colums directly, but select can be more performant
 });

, you can do this also in postgres with single CTE query:
WITH cte_insert AS (
          Insert into mytable (created_by, name)
          values
         ('SYSTEM','foo'),
         ('SYSTEM','bar'),
         (...)
         ON CONFLICT(name) DO NOTHING. # in case skipDuplicates: true and a unique constraint is defined to name, leave it away if skip dupicate is set to false
  Returning id, name, my_joined_table_id; # include the foreign key
        )
SELECT cte_insert.id, cte_insert.name, my_joined_table.baz JOIN my_joined_table ON cte_insert.my_joined_table_id=my_joined_table.id;

Currently we do this in our projects with 1000 of records in a performant way using raw queries.
In general i would say: If a developer is providing include or select in the createMany operation, evaluate it like the way here. If they are not defined, return the count like it is already implemented in prisma.
This would be awesome enable much flexibility! For update statements and i also mean for delete it is the same approach, since you can also use returning for update/(delete) statement. Assuming you want to get the deleted record for a deleteMany prisma query. So createMany, updateMany and deleteMany can be much boosted by this :)
Hope this helps.
Thanks a lot and best regards Andreas

This is needed!

+1 Just in case it makes a difference. I love Prisma and I'd love to see this feature implemented. I guess the number of use cases for bulk creation and the times you need it to return the just inserted records is really close. Also return the recently created resource in APIs development is a pretty accepted standard, why not with bulk operations?

This feature is essentially required.

Would be very nice to have someone from @prisma comment on this issue to clarify some expectations given the high activity on this issue.

+1 for this feature requirement

+1 Here to say that this is an absolutely essential feature, specially for database seeding!

1

It isn't neccesary to return the whole object either.
A better solution might be do return the primaryKey value ( assuming there is one ) and let the user do with that as they please

+1

This might be of interest for some of you: https://github.com/prisma/prisma/pull/24064#issuecomment-2093331715 (Feedback in the PR if this works as expected would be very welcome.)

Amazing, thanks for sharing. This will allow simplifying a bunch if insertion code. Looking forward to 5.14.

Hey folks, this feature will be released tomorrow as part of the 5.14.0 release for PostgreSQL, CockroachDB and SQLite. You'll find more about it in the release notes and the docs. Thanks!

woohoo! finally

And it's out, check our release notes at https://github.com/prisma/prisma/releases/tag/5.14.0 or the documentation at https://www.prisma.io/docs/orm/reference/prisma-client-reference#createmanyandreturn 🍾
If anything does not work, please open a new issue so we can directly triage and handle those. Thanks.

Thanks for tackling this

thanks prisma team

Thanks team P!

CreateManyAndReturn does not only return results but implementing it also returns a lot of thanks!
Thanks!

If you could add MongoDB to that list would be much appreciated 😃

Please open a new feature request for createtManyAndReturn() to support MongoDB @pyanda2.

Please add for SQL Server.

@YaakovR I think this needs to be a new issue as mentioned here

+1

does it implemented?

This was implemented in version 6 as createManyAndReturn.
https://www.prisma.io/blog/prisma-6-better-performance-more-flexibility-and-type-safe-sql#making-the-prisma-client-api-more-flexible

Thank you @wrheinheimer, it was not working for me, I just saw this comment which says that it is not supported for MySQL😕


v1.13 Backports 2024-03-11

[ ] #30988 (@tommyp1ckles)
[ ] #31014 (@tommyp1ckles)
[ ] #31159 (@pchaigno)
[ ] #31196 (@aanm)
[ ] #31015 (@learnitall)

PRs skipped due to conflicts:

#31292 (@chaunceyjiang) cc @sayboras

Once this PR is merged, a GitHub action will update the labels of these PRs:
 30988 31014 31159 31196 31015

/test-backport-1.13

#31292 (@chaunceyjiang) cc @sayboras

Noted and thanks, I will take care of the backport manually for 1.13.

/test-backport-1.13

/test-runtime

/test-backport-1.13


Fix PSAke Init Task to install Bot Framework Dependencies

The addition of the EchoBot from @smileyfist requires additional SDKs and other dependencies to be available in the build environment (AppVeyor CI and dev test machines).
The way to handle this is to update the PSAke Init Task to check for and install these dependencies.

Problem was just the PSake Init task just needed to run Nuget Restore before executing the build.


Merging DEVSKL from the old repo into the new repo

all tests pass at this stage; note that there were a number of API changes in the Optimizer module [I have split it into functional pieces] and if test coverage is not complete those may lead to issues when running the bot; therefore we should test it;
having said this -- all tests pass


Use full locale language/dialect when resolving messages

Handles https://github.com/Jasig/cas/issues/906

Will also manually merge with the 4.x branch once the pull is accepted.

+1

+1 to the change just a comment on whether we want to rely on implicit toString() or the actual method that would return the same value?

Good point. We should be using the toLanguageTag method per the docs. Thanks. I'll update the pull and merge.

Actually, I take that back. Using toString produces code_dialect which is consistent with our message bundles. Using toLanguageTag() uses code-dialect. So toString would work better with our setup as it is today unless we want to rename the bundles as well.


Add capacities extension

Description
Initial submission of the Capacities Raycast extension

Here's a demo of the integration
https://www.loom.com/share/c39943efff814f18b11ef62cf73a9ae2?sid=17b4afcb-f5a2-453e-a109-e71f078ab05c
If you want to test the integration yourself, you'll need Capacities Pro access. Please email us at<EMAIL_ADDRESS>for that.


Add Template workflows for xDIABOx/BattleTactics

To add GitHub Actions workflows to your repository:

create this issue
add a new comment with the content below
replace [repo name] with your repository name in the format owner/repo, e.g. BSData/test.

/template-workflows-pr xDIABOx/BattleTactics

/template-workflows-pr xDIABOx/BattleTactics


nixos/tomcat: add purifyOnStart option

With this option enabled, before creating file/directories/symlinks in baseDir according to configuration, old occurences of them are removed.
This prevents remainders of an old configuration (libraries, webapps, you name it) from persisting after activating a new configuration.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

The new version specifically keeps logs in place. Not sure if find is the best way to do it (with all the options), but it works fine.

Now, it is possible that people added their own files into baseDir and expect them to stay there after restart or reconfiguration; this patch will break their configuration. However, leaving bits of old configuration (especially old libraries or old webapps) may be even worse. Not sure how to handle this.
This PR, while it very much makes sense by itself, is a pre-requisite of another PR which would add management of the tomcat-users.xml file.

If deleting specific stuff is too clunky, an alternative is to write state into versioned dirs and use symlinks to point to whatever is current. That way old stuff can be garbage collected manually --- the tradeoff obviously being accumulating lots of junk over time & the overhead of managing the links ...

@Mic92 I replaced removal of "everything except logs" with removal of specific directories/symlinks.

@joachifm Did you mean versioning the whole tomcat directory? This would prevent loss of old files, but it's a solution that is way too "heavy" to be practical, and it doesn't prevent the main problem at hand: unexpected change of behaviour of the startup procedure.

For some reason, the previous commit actually did not include the advertised changes ("I replaced removal of "everything except logs" with removal of specific directories/symlinks"), now this is corrected by
fefcd78.
Any chance for merging this soon?

Just in case — @danbst do you want to comment on the list of directories to clean?

@pvgoran @7c6f434c
I think all good, but only enable if services.tomcat.purifyOnStart = true; is set (option to be created). Tomcat management is essentially stateful (the whole startup script is an example of this madness) and so many rely on this. For example, I have mutable webapp deploy to webapps dir - after this PR my webapp would be removed on tomcat restart (I can't put webapp into configuration.nix)

@danbst Makes sense. This new option is supposed to be disabled by default, right?

@danbst Makes sense. This new option is supposed to be disabled by default, right?

@pvgoran @7c6f434c
I think all good, but only enable if services.tomcat.purifyOnStart = true; is set (option to be created). Tomcat management is essentially
stateful (the whole startup script is an example of this madness) and so
many rely on this. For example, I have mutable webapp deploy to webapps
dir - after this PR my webapp would be removed on tomcat restart (I can't
put webapp into configuration.nix)
нд, 21 жовт. 2018 о 10:58 Michael Raskin<EMAIL_ADDRESS>пише:

Just in case — @danbst https://github.com/danbst do you want to comment
on the list of directories to clean?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/44303#issuecomment-431647551, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAtWkbFmH5s6mdZADsJUjO6IECZMJg1Sks5unCkvgaJpZM4VqfSm
.

@pvgoran right! It is pretty destructive feature. I also am not in favor of
changing defaults.
пн, 22 жовт. 2018 о 07:09 pvgoran<EMAIL_ADDRESS>пише:

@danbst https://github.com/danbst Makes sense. This new option is
supposed to be disabled by default, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/44303#issuecomment-431734518, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAtWkb3O-J0JH4vLrBPIw8ZPPmY-OZMLks5unUT-gaJpZM4VqfSm
.

«Once the option is added was precisely about purifyOnStart»

@danbst @Mic92 I added the purifyOnStart option to protect against removing things by default.
Now that it's in place, I'm thinking about going back to deleting everything (except the specifically preserved subdirectories) from baseDir, instead of deleting explicitly listed items. What do you think about it?

What is more likely, that they add one more directory we want to keep or that they add one more directory we want to clean?
Intuitively I would consider an explicit removal of known-problematic subdirectories (with a comment about what and why we still keep) the cleanest approach.

What is more likely, that they add one more directory we want to keep or that they add one more directory we want to clean?

Both of these look improbable to me, if we are talking about Tomcat developers adding something. NixOS developers, on the other hand, could add something; in this case, I think it will be rather something we want to clean.
But this is not how I see this choice. I think it's more about what to do with unknown files which were not created by NixOS: keep them or remove them? The currently implemented approach is "keep", but personally I'd prefer "remove".

But this is not how I see this choice. I think it's more about what to do with unknown files which were not created by NixOS: keep them or remove them? The currently implemented approach is "keep", but personally I'd prefer "remove".

What is your mental model of where these files would actually (probably) come from? Is there a need to add an option to extend the whitelist?

@pvgoran yes, you can remove everything. Those who don't want this behavior should remove purifyOnStart = true; declaration.
@7c6f434c

Is there a need to add an option to extend the whitelist?

Don't think so. Tomcat is pretty much stabilized software, which hasn't changed conceptually for ages.

What is your mental model of where these files would actually (probably) come from? Is there a need to add an option to extend the whitelist?
It could be something like custom logs, or data files/directories created by web applications. In this case, an explicit whitelist would be beneficial. However, I don't think this use case will appear (or at least appear frequently), so it's not worth adding an option now, until someone actually needs/requests it.

maybe leave logs?
Yes, and also work which (by default) contains session files.

@Mic92 Previously I switched from the "whitelist" approach (delete everything except selected directories) to the "blacklist" approach (delete only known directories that we create) by your request. Now, do you agree with going back to the "whitelist" approach with introduction of the purifyOnStart option?

What is your mental model of where these files would actually (probably) come from? Is there a need to add an option to extend the whitelist?
It could be something like custom logs, or data files/directories created by web applications. In this case, an explicit whitelist would be beneficial. However, I don't think this use case will appear (or at least appear frequently), so it's not worth adding an option now, until someone actually needs/requests it.

To me that sounds like an argument for a blacklist (if anything extra is created it is custom logs or data files, and we keep the known logs and session data files). But I won't use the module anyway.

To me that sounds like an argument for a blacklist (if anything extra is created it is custom logs or data files, and we keep the known logs and session data files). But I won't use the module anyway.

The thing is, this use case is just a speculation on my part, "what if someone does this". I have no evidence someone would actually need to organize files like this.

I implemented the "whitelist" approach (removing of all baseDir contents except for logs and work) in  #49729. I keep this PR as it is in case it will be preferred.
My preference is the "whitelist" approach (#49729), and I don't see strong arguments against it, now that the purifyOnStart option was added.
@Mic92 @7c6f434c @danbst Please review this and commit one of these two PRs, at last.

@7c6f434c @pvgoran on second thought, I'd prefer this one, "blacklist" approach. Because we allow users to change baseDir, someone can set it to /home/XXX, and eventually add purifyOnStart. Which will be uh-oh. With current approach the disaster won't be that large, as with "whitelist" approach.

I do not claim arguments for blacklist are strong, it is all about reasonable arguments on both sides. And now this bikeshed is freshly painted. Thanks to everyone.


AMD, GDM, GNOME: FreeBSD bugs 253746 and 257810

Under https://old.reddit.com/r/freebsd/comments/xpmn0z/ I mention FreeBSD bugs:

253746 – x11-wm/mutter: Freezes on AMD GPU's with DRI3
257810 – x11/gnome3(-lite) & x11/gdm lags significantly on amdgpu

The first answer there suggested desktop-installer. I wonder, does the script alert the end user if there's the aim to use GNOME with AMD graphics?

No, I don't want to get into the business of chasing individual bugs in underlying software.
What I could potentially do is enhance the general warnings in auto-gpu-setup to educate users about possibilities like this one.  I'll give some thought to how it should be presented.

I made some small improvements to the text and committed sysutils/auto-admin so they will appear in the next branch.  We can make further improvements if you have any ideas.


Some images are being loaded from github

Steps to Reproduce

Visit a page on production open edx, like https://courses.mitxonline.mit.edu/learn/course/course-v1:MITxT+14.310x+3T2022/home

Expected Behavior
All MIT-specific resources should be loaded from mitxonline.mit.edu or the CDN.
Actual Behavior
logo.png and favicon.ico are loading from githubusercontent.com!
Screenshot or Screencast

Once we figure out how this is happening, we should take a look at xPRO and Residential as well.

These images are kept in our code base as static assets https://github.com/mitodl/mitxpro-theme/tree/master/lms/static/images. Actually, we have just overridden it. This is how edX does https://github.com/mitodl/edx-platform/tree/master/lms/static/images and we cannot do anything about this. If we still want to do something about it please let me know.
CC: @pdpinch

I understand these are the correct images, but the URLs are wrong. End-users shouldn't be getting these images via github.com URLs. They should be coming from courses.mitxonline.mit.edu, or maybe the CDN.
@mitodl/devops is there something wrong with our configuration, or the deployment of this theme?
I did a quick search of the theme repo and didn't see any hard-coded links to raw.githubusercontent

This happens for the learning MFE only. For all the other tabs like progress, the URL is https://courses.mitxonline.mit.edu/static/mitxonline/images/logo.0a44f80f6467.png. Not really sure what's wrong with the learning MFE. Digging a bit more into the Learning MFE.

logo.png and favicon.ico are set in .env and are coming from https://github.com/mitodl/ol-infrastructure/blob/c30a498638c6f2cfda797724f579e91687e76c33/src/ol_concourse/pipelines/open_edx/mfe/values.py#L10. @mitodl/devops | @blarghmatey Could we change this?

This can be changed and will require us to update the pipeline to push those images to S3 and then load them through Fastly instead of GitHub.

update the pipeline to push those images to S3 and then load them through Fastly instead of GitHub.

@blarghmatey how big of an effort is this?
We're updating the logos now in https://github.com/mitodl/ol-infrastructure/pull/2270 and it just seems wrong to me to serve them from raw.githubusercontent.com!

We're updating the logos now in https://github.com/mitodl/ol-infrastructure/pull/2270 and it just seems wrong to me to serve them from raw.githubusercontent.com!

@pdpinch Tobias was suggesting the use of raw.githubusercontent.com in https://github.com/mitodl/hq/discussions/3778#discussioncomment-8801934. I think he missed your above comment. Should I use GitHub for MITx or should I wait?
@blarghmatey FYI

@pdpinch is this ready to be closed now?

I'm still seeing the logo and two (?) requests for the favicon going to raw.githubusercontent.com from the page at https://courses.mitxonline.mit.edu/learn/course/course-v1:MITxT+14.310x+3T2022/home
https://raw.githubusercontent.com/mitodl/mitxonline-theme/main/lms/static/images/logo.png
https://raw.githubusercontent.com/mitodl/mitxonline-theme/main/lms/static/images/favicon.ico

On the Studio side, everything seems to come from courses.mitxonline.mit.edu, which is better. I tested an MFE page and a legacy theme page.

The corresponding logos in QA are loading from the theme rather than GitHub, so I am going to close this as all of the necessary configuration changes have been made. We are just waiting on a production deploy of edX and MFEs for MITx Online.


initial setup

initialise the new react app
add linters
add a readme file
add license
fix linters

Hi Tinashe,
Your project is complete! There is nothing else to say other than... it's time to merge it :shipit: Congratulations! 🎉
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Thank you @mikethreels!


Manually add libtorch op test

We want the test to run in integration-gpu in the CI, but currently it is not picked up there and on the CPU, we do not have PyTorch. I would not know why it is not tried on the gpu-enabled CI run.

So the PyTorch version we are using has the old, incompatible DLPack.
Quite likely this means we cannot enable the libtorch op before we move to PyTorch 1.11.
Would that be feasible?

@masahi Do you think bumping to PyTorch 1.11 would be an option?

I'm attempting to bump the version in #10794

I'm testing the new docker image in ci-docker-staging. I've hit an error from Keras twice https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/ci-docker-staging/242/pipeline/315, not sure if it is related or flaky. There is also an error from ONNX tests that use PyTorch.

The keras looks like it's some compat-breaking change somewhere, I don't know if we accidentally (or intentionally) upgraded that...
I'll check the ONNX change, maybe the input has been renamed (I'm not sure that they would be terribly stable unless specified), but likely not before tomorrow.

No worry, I fixed both issues and the test passed https://github.com/apache/tvm/tree/ci-docker-staging. I will send a pr tomorrow

Awesome! Thank you!

[2022-04-01T19:22:29.075Z] /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libcuda.so: file not recognized: File truncated
[2022-04-01T19:22:29.075Z] collect2: error: ld returned 1 exit status
[2022-04-01T19:22:29.075Z] CMakeFiles/tvm_runtime.dir/build.make:253: recipe for target 'libtvm_runtime.so' failed
[2022-04-01T19:22:29.075Z] make[2]: Leaving directory '/workspace/build'
[2022-04-01T19:22:29.075Z] make[2]: *** [libtvm_runtime.so] Error 1

any ideas what that could be about?

No idea, this happens only when linked with libtorch.so, right?
https://discuss.pytorch.org/t/building-pytorch-from-source-failed-on-ubuntu-16-04/43026 suggests our cuda install is broken, but since CI has passed with PT 1.11, I don't think that's the case.
One thing that could be related is that our ci-gpu is using fairly old cuda - 11.0 according to https://github.com/apache/tvm/blob/main/docker/Dockerfile.ci_gpu#L20. Maybe this is incompatible with the latest libtorch.so? Even if that's the case, I don't get why we didn't get any errors on the CI test.
In the worst case, we can install CPU-version of PT, since we don't need cuda capability for CI purpose.
cc @driazati

So I wonder if it's that libtorch and tvm try to link to different versions of libcuda...

When we install torch via pip install torch==1.11.0, how do we know which cuda it was built against? Maybe we should explicitly specify the cuda version as in https://pytorch.org/ (pip3 install torch -extra-index-url https://download.pytorch.org/whl/cu113). But a better way is still to install a CPU-only version.
Or we can try updating our NVIDIA container image to update cuda itself (we should do that anyway sooner or later). I don't know what process is required for that.

How do we know which cuda it was built against?
I think mostly from looking at the CUDA version it advertises on https://pytorch.org/get-started/locally/ (for the current PyTorch CUDA 10.2).
If the problem is only when linking libtvm and libtorch, a CPU-only PyTorch could solve this or maybe just finding a PyTorch enabled CPU instance to build the fallback and run this test on.

So some of the tests seem to look at whether cuda is available to torch. We could go over these and avoid that - I'm wondering whether the the measure_latency function is used at all btw.
https://github.com/apache/tvm/blob/41cfd3d92d1ccd397b76ac45075ccddcf7da6628/tests/python/frontend/pytorch/test_forward.py#L127
Another idea could be to use a CPU-only PyTorch in the build setup and then use a GPU-enabled one in the testing if the problem is mainly with the linkage of libtvm->libtorch->cuda...

I'm wondering whether the the measure_latency function is used at all btw.

That's a left over from the initial PR from AWS. It is completely irrelevant and should be removed.
We never need GPU-enabled PT for testing purposes. To avoid driver-related problems in the future, we should switch to CPU-only build.

Thank you. I'll send a PR.

We can come back to this now. Recently when I tried to test PyTorchTVM stuff https://github.com/apache/tvm/pull/8777,  I hit an undefined symbol issue from libtorch. So even though we cleared cuda issues, I fear we might encounter another issues.

I hit an undefined symbol issue from libtorch. So even though we cleared cuda issues, I fear we might encounter another issues.

Was this with libtorch symbols?
I think the libtorch ABI is not terribly stable (to put it mildly) but if we use the exact same libtorch distribution (and my understanding is that we do in the CI), it should work.
I rarely hit this particular problem, because I use a global PyTorch installation for everything, but then I always get missing symbols if I update PyTorch without updating the auxiliary libraries that have extension modules...

It's the same problem as https://discuss.tvm.apache.org/t/can-someone-please-give-me-the-steps-to-use-pt-tvmdsoop/12525, something related to GLIBCXX_USE_CXX11_ABI issues apparently.

Yeah. So I think the official PyTorch Python packages don't use the "new" C++ API due to Python module conventions buried somewhere...

So I'm having trouble to reproduce the exact failure on my dev machine, but I use newer cmake (not sure if that matters, but I don't have a good idea as to what that error message wants to tell me...)

but I don't have a good idea as to what that error message wants to tell me...

You mean the error $<COMPILE_LANGUAGE:...> Unknown language. from https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/PR-10758/9/pipeline/?
Note that updating Dockerfile for cmake requires going through another CI image update process.

I don't really know if the cmake version is the problem as I have not been able to reproduce it locally nor do I fully understand the error message. So I guess it's nontrivial to find out in the CI if updating cmake helps. :/
If you had any advice, I'd gladly follow it.

No idea either, my cmake-fu is very low unfortunately...

After quite a bit of work, I have reproduced the failure locally and can confirm that bumping cmake to the version compiled from source does solve the error.

Of course, if a bump of the ubuntu base were immanent, that could be an alternative.

I see, I don't know if we are updating ubuntu any time soon (cc @driazati), so can you send docker/Dockerfile.ci_gpu change in a separate PR?

sorry for my delays, I was able to repro the error using tests/scripts/ci.py:
gh pr checkout -f 10758
# errors out
python tests/scripts/ci.py gpu

upgrading to cmake 3.11.4 (via this patch to ci.py) seems to fix it and the build finishes successfully though
diff --git a/tests/scripts/ci.py b/tests/scripts/ci.py
index c0ce085ff..4ee9725e7 100755
--- a/tests/scripts/ci.py
+++ b/tests/scripts/ci.py
@@ -370,10 +370,22 @@ def generate_command(
         if precheck is not None:
             precheck()

+        cmake_stuff = [
+            "sudo apt remove -y cmake",
+            "rm -rf CMake",
+            "git clone --branch v3.11.4 https://github.com/Kitware/CMake.git --depth=1",
+            "pushd CMake",
+            "./configure --parallel=24",
+            "make -j24",
+            "sudo ln -s $(pwd)/bin/cmake /usr/bin/cmake",
+            "popd",
+            "cmake --version",
+        ]
+
         if skip_build:
             scripts = []
         else:
-            scripts = [
+            scripts = cmake_stuff + [
                 f"./tests/scripts/task_config_build_{name}.sh {get_build_dir(name)}",
                 f"./tests/scripts/task_build.py --build-dir {get_build_dir(name)}",
                 # This can be removed once https://github.com/apache/tvm/pull/10257

then re-running
tests/scripts/ci.py gpu

so upgrading cmake to 3.11.4 in CI seems like the best way to go (we're on 3.10 right now), so @t-vi if ubuntu_install_cmake_source.sh builds cmake 3.11.4 that'd be good

I've submitted the build with the new cmake. Thank you for patiently helping me.

So it seems that the libtorch linked into TVM and the libtorch that the PyTorch wants are incompatible now. :/
I will check if it is possible to only have the linked-to-libtorch symbols locally visible in the hope that they don't interfere then, but I'm not sure that that'll work.


Small rectangle appears momentarily on the the repost icon in the channel feed

DESCRIPTION:
Small rectangle appears momentarily on the the repost icon in the channel feed.  This occurs when first loading the page, and then it disappears. If you scroll down and back up the rectangle will appear again.

REPRO STEPS:

Install and Launch LBRY 0.16.0 on Android 8.1.0
Login to an existing account
View a Channel with Reposts

Results:  Repost icon has a rectangle on it for a moment
Expected: Repost icon did not have a rectangle on it

ENVIRONMENT:

LG V20
Android 8.1.0
LBRY 0.16.0

MEDIA:

INTERNAL USE:

DEFINITION OF DONE:

[ ] Tested against acceptance criteria
[ ] Tested against the assumptions of the user story
[ ] The project builds without errors
[ ] Unit tests are written and passing
[ ] Tests on devices/browsers listed in the issue have passed
[ ] QA performed & issues resolved
[ ] Refactoring completed
[ ] Any configuration or build changes documented
[ ] Documentation updated
[ ] Peer Code Review performed

LBRY ADDRESS:
bZSqrVdpxt5KJdn2eGMUzT9Jn3gEiRet7b
<EMAIL_ADDRESS>

That's strange - not seeing this or the one you filed for the wallet page. Maybe @akinwale has some ideas.


Code fix. Added missing @ for the variable remote_coopr_dir

Oops. Not sure how that squeaked by! Thanks for catching it.


Added test for LiveStreamAggregation code file generation

Changed LiveStreamAggregation implementation to set the SkipSchemaGeneration property for DocumentMapping instead of entirely removing it from storage.
Updated implementation for schema generation to skip such mappings.
It's more hotfix, than a real revamp, but without introducing breaking changes, it'll be harder to change it.
Fixes #2645
Relates to #2610

@jeremydmiller said gave me no points for style but approved on Discord so I'm merging that 😉


UnhandledPromiseRejectionWarning

hi,
i get these errors since 2.0.4:
node:841) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which wa
node-red.0	2019-10-21 10:59:46.542	warn	(node:841) UnhandledPromiseRejectionWarning: Error: Huejay: connect ENETUNREACH <IP_ADDRESS>:80 at getHttpClient.request.then.catch.error (/opt/iobroker/iobroker-data/node-red/node_modules/hueja
Gruß frAnk

Hi Frank! Do you use NodeJS 10.x or higher?

Moin Foddy,
it is NodeJS '8.16.2'
Gruß frAnk

Hi frAnk,
I‘m pretty sure that this causes the error. Please upgrade to NodeJS 10+ if this is not conflicting with any other modules and try again.
Grüße zurück ;)

hi foddy,
ich have upgrade, but i got the same error!
node -v
v10.17.0
npm -v
6.11.3
Gruß frAnk

i have no <IP_ADDRESS>:80  in my network!

======
4 Nov 10:02:13 - [info] Node-RED Version: v1.0.2
4 Nov 10:02:13 - [info] Node.js  Version: v11.5.0
4 Nov 10:02:13 - [info] Linux 3.14-1-amd64 x64 LE
4 Nov 10:02:13 - [info] Paletten-Nodes werden geladen
4 Nov 10:02:13 - [debug] Module: node-red-contrib-bigtimer 2.2.5
======
root@deb8mpd-virt:~/.node-red# npm -v
6.12.0
node:17401) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 289)
(node:17401) UnhandledPromiseRejectionWarning: Error: Huejay: Request failed with status code 404
    at getHttpClient.request.then.catch.error (/root/.node-red/node_modules/huejay/lib/Transport.js:106:15)
    at process.internalTickCallback (internal/process/next_tick.js:77:7)
(node:17401) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 291)
(node:17401) UnhandledPromiseRejectionWarning: Error: Huejay: Request failed with status code 404
    at getHttpClient.request.then.catch.error (/root/.node-red/node_modules/huejay/lib/Transport.js:106:15)
    at process.internalTickCallback (internal/process/next_tick.js:77:7)
(node:17401) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 293)
4 Nov 10:01:13 - [debug] [hue-bridge:Hue Bridge] Error: Huejay: Request failed with status code 404
    at getHttpClient.request.then.catch.error (/root/.node-red/node_modules/huejay/lib/Transport.js:106:15)
    at process.internalTickCallback (internal/process/next_tick.js:77:7)
(node:17401) UnhandledPromiseRejectionWarning: Error: Huejay: Request failed with status code 404
    at getHttpClient.request.then.catch.error (/root/.node-red/node_modules/huejay/lib/Transport.js:106:15)
    at process.internalTickCallback (internal/process/next_tick.js:77:7)
(node:17401) Unhandled

any help welcome

i uninstalled huemagic und now have this error
4 Nov 10:05:51 - [info] Warten auf fehlende Typen, die registriert werden sollen:
4 Nov 10:05:51 - [info]  - hue-bridge

what to do now?

node -v: v10.18.0
npm -v : 6.13.4
Node-Red: 1.0.3
I have the following errors every couple of 10 minutes or so:
(node:15765) UnhandledPromiseRejectionWarning: Error: Huejay: connect ENETUNREACH <IP_ADDRESS>:80 - Local (<IP_ADDRESS>:0) at getHttpClient.request.then.catch.error (/home/pi/.node-red/node_modules/huejay/lib/Transport.js:106:15) at process._tickCallback (internal/process/next_tick.js:68:7) (node:15765) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 50)
I have attached pictures of the flows and ui produced.
This is all on a Raspberry 4. I also have a Raspberry Zero W - same issues - however, the Zero seems to have a much harder time recovering form the error (becomes unresponsive for long (5 to 7 minutes) periods of time. The Pi 4 doesn't seem interrupted; just produces the error.

@Lastat77
i cannot help with the problem, but i find the flow interesing.
Would you mind sharing it here (as an export from node-red) ?
greatly  appreciated, and thx,
toz

@ozett
Hopefully the error can be addressed at some point.
Attached are .json of the flows. I have removed the HUE's key/user id code and the HUE Bridge name. Also, the GPIO's are disabled in case your PIN usage is different and present.
flows.zip

I have the same problem.
(node:17022) UnhandledPromiseRejectionWarning: Error: Huejay: Request failed with status code 404
at getHttpClient.request.then.catch.error (/home/pi/.node-red/node_modules/huejay/lib/Transport.js:106:15)
at process._tickCallback (internal/process/next_tick.js:68:7)
(node:17022) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 479)

It has been working, but not anymore. I hope someone can throw some light on this issue.

Yeah, still here... If I use flows that include this set of nodes, the PI becomes basically frozen after just a bit of use (couple minutes/10/20 clicks). Sometimes I can ssh to it and reboot, but often it has to be hard bounced.
I have re-imaged, switched power cords, switched sd cards; tried everything. Only thing that works is to not use this node - which isn't really an option since this node, when working, is really great. I even tried using dietpi over rasbian - no different (if not worse).
So now I have a cron job to reboot the pi every hour. Not ideal (and ironically, as I type this, I am unable to get to the pi again).

My Pi doesn't freeze. I just can't find the diyHue bridge when creating the flow. My Philips Hue bridge is visible and I can use that in the flow.
The strange thing is that it has worked (diyHue with Node Red).
I will setup a new Pi and see if it works there.
It would already help if we can find out if the problem is in the HueMagic node or in the diyHue (or even somewhere else).

Seems from the error I read, the underlying issue is actually HueJay and the node not catching it "properly". (not a knowledgable expert here).

I have exact the same problem. It seems that it happens when there is a good hick up in the network where Node-RED is running. This will causes a stop of reading data back from the Hue Bridge. You can send commands to the Hue Bridge, but not read data back.
My test
I tested it by making a small flow with a light and two injections. One with {"On":true} and one with {"On":false} to turn the bulf on or off. When I noticed that the Hue Magic nodes were hanging, I checked if this simple flow was able to turn to bulb on and off. The real bulb was going on and off, but the status of the bulb remained off in Node-RED. When you deploy new nodes that contains a Hue Magic Node the problem is gone. Every node gives back the status of the devices/scenes etc.. Same by deploy all or restart the node red service. Deploy with modified nodes does not fix this issue.
My configuration
My problem is caused on Hue Magic on Rpi3 with a very low CPU load. But I know that my Pi has sometimes some network issues.
Analysis
I think that this might be the issue together that the Node-RED reports about a catch issue in the code.

Mar 22 08:32:42 framframmetje Node-RED[7812]: (node:7812) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 5)
Mar 22 08:32:42 framframmetje Node-RED[7812]: (node:7812) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I took a small peek in the code of Hue Magic to see if I can find the root cause, but was unable to get in to the code. Perhaps you, as programmer, know directly where the problem should be.
I checked the syslog etc. if there were other things going on. I've analyzed several hangs and couldn't find any correlations. I have detailed information of a hang, because I send the temperature of a Hue sensor to the cloud. When Hue Magic hangs, no data is received.

More information. My Hue nodes were hangin on one flow only.
Flow light control had old data instead of status waiting... But my new flow with only the bulb and two injections were working fine. The real bulb's status was read in the node in this test flow.
In the syslog I see that the error of UnhandledPromises came up several times today

I'm getting this as well.  I have been for some time. It's causing significant errors.
NodeJS 12.18.2
NodeRed 1.1.1
NPM 6.14.5
Latest HueMagic nodes.
I also get the unhandled error on startup too.

I have also updated everything to latest versions. Issue still present. But the auto-reboot (cron) I employed makes it all OK in a sense. In my use case, a reboot every hour is fine - and probably a bit overkill. Could probably just reboot nightly.

I noticed that it happens when my network has a heavy load. I think a time out is the root cause fo this.

I made some progress to find the root cause of this. It seems that in Huejay the handling of network feedback from the bridge need improvement.
I notice that this only occurs when my network has heavy load to handle or my Pi is busy.  When you've a Pi, the huejay responds slower that a fast Intel-based computer. That could explain why you will see this more or only on the Pies than a PC.
When I made a test to send a lot of data to the HueBridge I saw the feedback from the Bridge to slow down, but the flows ignore this. Then the Hue Bridge will disconnect the nodes for small time. A proper flow should stop sending when the receiver gives a signal to slow down. The same is that the nodes don't reset connection when a time out occurs.

https://github.com/sqmk/huejay/issues/115

I made some progress to find the root cause of this. It seems that in Huejay the handling of network feedback from the bridge need improvement.
I notice that this only occurs when my network has heavy load to handle or my Pi is busy. When you've a Pi, the huejay responds slower that a fast Intel-based computer. That could explain why you will see this more or only on the Pies than a PC.
When I made a test to send a lot of data to the HueBridge I saw the feedback from the Bridge to slow down, but the flows ignore this. Then the Hue Bridge will disconnect the nodes for small time. A proper flow should stop sending when the receiver gives a signal to slow down. The same is that the nodes don't reset connection when a time out occurs.

I hope this able to be resolved soon. I'm using a OdroidN2 to host Node Red, and it doesnt do anything else.  It should have enough power to handle these Hue commands.

+1 with the same issue :-(
(node:5816) UnhandledPromiseRejectionWarning: Error: Huejay: timeout of 15000ms exceeded     at /home/pi/.node-red/node_modules/huejay/lib/Transport.js:106:15     at runMicrotasks (<anonymous>)     at processTicksAndRejections (internal/process/task_queues.js:93:5)     at runNextTicks (internal/process/task_queues.js:62:3)     at listOnTimeout (internal/timers.js:523:9)     at processTimers (internal/timers.js:497:7) (node:5816) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 166)

Fixed with the v4 update :)


Sample plot legend text cut off?

to replicate: produce a standalone rrv plot with the category set to "age" for the DEICODE pseudomonas dataset.
TODOs for diagnosing the problem:

check if generating a Q2 plot also exhibits this error (I would imagine so, but you never know)

Yeah, the Q2 plot has this as well.

check if other numeric fields also exhibit this error
try replicating this with smaller datasets
look into if other people have had this problem with vega/vega-lite/vega-embed/altair

Weirdly enough, changing the config width/height fields of the sample plot JSON doesn't seem to fix this: making them really huge just makes the chart larger, and the legend text is still cut off. Resizing the samplePlot div via CSS doesn't seem to change anything, either (the sample plot retains its set size via the JSON config).

Updates:

The problem doesn't manifest when you load the sample plot JSON in the online Vega Editor.
Increasing the width of the sample plot view after the fact (using view.setState()) also addresses the problem.

Not 100% sure of a solution yet, but this brings us closer.

Ok, so it turns out that you don't even need to increase the width with setState -- just changing it at all seems to fix this problem.
I have no idea why this is the case, but a really rudimentary solution would just be to automatically call setState(getState) after loading the chart, which would fix this, right? So it looks like you have to at least change the width somewhat. A better (albeit hacky) solution is just increasing the sample plot width by 1 immediately after loading the chart. Should probably report this as a vega-embed bug, I guess.

I'm not so sure hacky fixes are the way to go about this. If you select a metadata field with a ton of possible values (e.g. a unique field for each sample, like the sample ID), then the sample plot legend immediately gets overwhelmed with like hundreds of options -- and if you fix things to make the sample plot adjust to the size of the legend, then the page's formatting gets destroyed as everything shifts to accommodate the massively tall plot that was just created.
The way emperor gets around this sorta thing is by having a sidebar where you can control the various properties of the visualization -- so long lists, etc. just make the songbird scroll without impacting the rest of the page.
I think it should be feasible to drop the color legend (as well as other legends like size, etc. if we expose those to the user) from the sample plot, and instead just make it configurable in a sidebar or something. This would negate most of these problems, along with ensuring that the rank and sample plots stay nice and simple.

Yeah, I just spent a while messing with labelLimit, etc. in Vega and Vega-Lite specs alike and haven't been able to resolve this problem. Probably best to cut ties with Vega legend stuff in the future.

Also, I've noticed that the y-axis label in the sample plot is also cut off sometimes. Less important, but still would be good to preserve (or just remove entirely I guess).

...wait. There's an autosize parameter? https://github.com/vega/vega-embed/issues/91
So this issue's been going on for two months and I only realized this after I fixed it another way?
uh sure fine


renderTitle image not shown on all device

"react-native-router-flux": "3.38.0"
I rendered the title as an image:
const logo = require('../media/logo.png');
const NavBarImage = () => {
    return (
        <View style={{ alignItems: 'center', marginTop: 16 }}>
            <Image
                style={{ width: 200, height: 24 }}
                source={logo}
            />
        </View>
    );
};

But there is few phone where the image not shown. I tested on Sony Xperia XZ, OnPlus 3G and it was there, but on OnePlus 2 it isn't. The other images which is loaded on the same way to the application (like const logo = require('../media/logo.png');) working properly only the renderTitle have this error.
Do you have any idea why is it happening?

v3 is not supported, sorry. Please try v4.

I didn't found any stable version under v4. I got the BackHandler error like the #1894  and I think it is using newer React Native which is breaking some other dependency.
Thank you, but I think currently my application not supporting the v4.


logger is undefined in downloadOWJar function

The function downloadOWJar is called with no logger so when this line [1] tries to log something, it fails
[1] https://github.com/adobe/aio-app-scripts/blob/3c6fc2bbfe6f53092fce55f9787513d4de803fb6/lib/utils.js#L185
This is the place that this function is called from:
https://github.com/adobe/aio-app-scripts/blob/3c6fc2bbfe6f53092fce55f9787513d4de803fb6/scripts/dev.js#L64

@OmarEltobgy thank you very much for reporting, fixed in #33


docs: update tauri url

Tauri plugin repo changed it's branch structure, so the link had a 404.

Thanks!


Doesn't support FormArray?

It appears this may not support FormArray, or is there some way to do it I don't understand?
<form [formGroup]="workplanForm">
...
<div formArrayName="workplan_items">
  <div *ngFor="let w of workplanForm.controls.workplan_items.controls; let i=index">
    <div [formGroupName]="i">
      <ng-select formControlName="colleges"
        [options]="colleges_options" multiple="true" placeholder="Select colleges">
      </ng-select>
...

  ngOnInit() {
    // _fb is a FormBuilder
    this.workplanForm = this._fb.group({
        workplan_items: this._fb.array([
            this._fb.group({
              colleges: ['']
              })
        ])
    });
}

When I render the page, I get:
error_handler.js:45 EXCEPTION: Error in ./WorkplanComponent class WorkplanComponent - inline template:0:6 caused by: There is no FormControl instance attached to form control element with path: 'workplan_items -> 0 -> colleges'
error_handler.js:47 ORIGINAL EXCEPTION: There is no FormControl instance attached to form control element with path: 'workplan_items -> 0 -> colleges'
error_handler.js:51 Error: There is no FormControl instance attached to form control element with path: 'workplan_items -> 0 -> colleges'
    at _throwError (http://localhost:4200/main.bundle.js:10068:11)
    at _noControlError (http://localhost:4200/main.bundle.js:10055:12)
    at SelectComponent.onChange (http://localhost:4200/main.bundle.js:10041:61)
    at SelectComponent.updateSelection (http://localhost:4200/main.bundle.js:68247:14)
    at SelectComponent.writeValue (http://localhost:4200/main.bundle.js:68292:14)
    at setUpControl (http://localhost:4200/main.bundle.js:10011:23)
    at http://localhost:4200/main.bundle.js:14994:105
    at Array.forEach (native)
    at FormGroupDirective._updateDomValue (http://localhost:4200/main.bundle.js:14989:25)
    at FormGroupDirective.ngOnChanges (http://localhost:4200/main.bundle.js:14924:18)
...

Actually, it was pretty trivial, I just had to change the FormBuilder definition to reflect that it was a multiple select (e.g. use an array):
this.workplanForm = this._fb.group({
        workplan_items: this._fb.array([
            this._fb.group({
              colleges: [[]]
              })
        ])
    });


Appstudio update mvp-test-component

Pipelines as Code configuration proposal

Pipelines as Code CI/mvp-test-component-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
6 seconds
init

✅ Succeeded
16 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
17 seconds
clair-scan

✅ Succeeded
17 seconds
sanity-inspect-image

✅ Succeeded
16 seconds
deprecated-base-image-check

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
1 minute
sbom-json-check

✅ Succeeded
8 seconds
sanity-label-check

✅ Succeeded
8 seconds
sanity-optional-label-check

✅ Succeeded
4 seconds
show-summary


move order of middleware definitions

The current example doesn't work because of the order we define the middlewares.
More context on https://github.com/bithavoc/express-winston/issues/169

thanks for the input @makrandgupta , will update accordingly


Import Lzokay and Implement it's compressor, while lz4 was moved into third_party.

This file should also be updated.