Poll - What would you like to see in the future versions of objection?

I'm starting to plan the 2.0 release and I'd like to hear the community's opinions what we should add to objection in 2.0 or later down the road.
I'd like to reiterate here that the goal of objection was never to become Eloquent, Django's ORM, Active Record or any other known ORM. Objection's goal is said pretty well at the top of the github README. Objection is a "query builder on steroids" that never get's in the way of SQL, but still attempts to provide tools for working with repetitive stuff and especially relations.
That said, there are many things those ORMs do better than objection and we should try to bring in the features that suit objection's design goal.
SO, I'd like you to post here what you miss from any other tool you've worked with and think objection should really have. Vote the features using :+1: and :-1:
Couple of things 2.0 will have:

A more usable and consistent static hook system that fixes most if not all issues I've seen people having. The instance hooks will still be around. They have their use cases.
More consistent naming of methods and concepts. For example eager is used as a verb, even though it's not, joinRelation implies it joins a single relation. joinEager sounds like joinRelation even though it does a very different thing. These will be something like withGraphFetched, joinRelated, withGraphJoined. etc. The old names will remain as aliases at least until 3.0.

https://github.com/Vincit/objection.js/projects/1

I concede the following is quite niche so feel free to shoot it down :)
One thing I've always missed (and due to that I've implemented myself) is functionality similar to JPA's @Embeddable/@Embedded for logical grouping of related fields in a single table.

@tonisostrat I'll try not to shoot down anything or add my own opinions here to not affect the discussion.

This may be more on the knex-level, but being able to selectively run seeds would be nice.
Also maybe seeing tools like https://github.com/Vincit/knex-db-manager, https://github.com/Vincit/objection-db-errors, and https://github.com/Vincit/objection-find become a part of the core or have better visibility and code examples in the docs, to help folks write less boiler plate initially.

+1 to @heisian 's note for at least https://github.com/Vincit/objection-db-errors (only b/c I'm not familiar with the other 2; thanks for sharing those links, good weekend reading :) ). My coworkers and I have started to default to pulling in that plugin on our projects, really appreciate the extra support on error handling. No opinion / suggestion (helpful or otherwise) on where to go with that, but lowering the barrier to entry for that utility somehow I think would be a really solid addition.
(ps Objection is ill! Thanks for all your work here (and for polling for feedback on v2; looking forward to it))

Would a @column('columnName') property decorator be appropriate? You'd use it to decorate a property of a model and the default (or base class) columnNameMapper would consult this property when performing the mapping.
e.g.
class Singer extends Model {
    static table = 'singer';

    @column('pseudonym')
    name: string;
}

would yield code models with a name property whose value would be used to populate the pseudonym column when a Singer instance is insert()ed, for example.

More support with knex's up, down migrations (and also seeds) would be very interesting. It could be generated from existing Model code if we have more typings like @GreatSchool2 mentioned.
Currently, I work with custom up, down, seed methods in Model classes that I query for all my models to generate a database from scratch, and maintaining the ordering of what should be created first by hand via a simple numbering system that could probably be derived from the relationship graph.
Fixture-esque stuff like can be found in Ruby in Rails is severely lacking in Node.js in general, and it's almost required to test with the database in mind instead of mocking everything. It's a complicated topic when dealing with relational databases, since it's just a pain to put stuff in the right order (I just disable all checking, and for initial testing data that's ok, but it gets messier with "partial updating", for which we have graph functions for).
I also agree with the naming, and would like to see custom behavior for joinRelation also (filters like we have in eager).

I would like:

An option to mix WhereInEagerAlgorithm and JoinEagerAlgorithm in a single query.
An option to create two aliases for a single relation, i.e.
rel1 as creditors(whereRoleIsCreditor),
rel2 as debtors(whereRoleIsDebtor)

If you create a bounty for these feature I will donate. (hopefully others will donate too)
Thank you for your efforts

Support for for await (...) loops would be nice. Especially if it's backed by cursors. This could fallback to limit/offset, even though that doesn't have the same performance (but still ~constant memory pressure).
for await (let person of People.query()) {
  ...
}

You can kinda get this by using knex stream interface, as Readable streams support asyncIterator since v10.0.0. Though when I did this I had to use People.query().build().stream() which feels a bit clunky.

Currently, I work with custom up, down methods in Model classes that I query for all my models to generate a database from scratch, and maintaining the ordering of what should be created first by hand via a simple numbering system.
But I don't ask to implement the management of that at all; I would like however, a way to generate the ordering from relationship graphs, for example.
I also agree with the naming, and would like to see custom behavior for joinRelation also (filters like we have in eager).

I don't understand.. this library is based on knex which already handles migrations/changelogs, why don't you utilize it?

Currently, I work with custom up, down methods in Model classes that I query for all my models to generate a database from scratch, and maintaining the ordering of what should be created first by hand via a simple numbering system.
But I don't ask to implement the management of that at all; I would like however, a way to generate the ordering from relationship graphs, for example.
I also agree with the naming, and would like to see custom behavior for joinRelation also (filters like we have in eager).

I don't understand.. this library is based on knex which already handles migrations/changelogs, why don't you utilize it?

In a way, you're right. But I don't like how migrations separate the creation of tables from the Model object itself. It's perhaps a bit more cumbersome, but it's sure convenient!
Regardless, I should probably move to the knex migration way, I think the support for MS SQL is improved now, and it's way better for my own sanity. Thanks!

I have a handful of thoughts.  Given that objection is overall fairly stable and feature-complete, I think the focus should be on using a breaking change (i.e. v2.0) to tighten things up: focus on naming, making any notable alterations to queries, fixing API warts, working on related tooling.  You know, things that are worth considering only when there isn't a ton of debt to pay off.  It's my impression that there isn't!
I'll just list some ideas, and not so much propose specific solutions, although I'd be happy to talk about solutions if we want to peel-off some additional github issues.

Passing arguments to modifiers
Currently modify() doesn't directly extend knex's behavior because you can't pass them arguments.  I think there's an issue for this https://github.com/Vincit/objection.js/issues/1293.  There's an additional inconsistency, where there's no interface for providing arguments to modifiers referenced in relation expressions.

Relation modifiers coupled to eager algorithm
Currently relation modifiers are implicitly coupled to whichever eager algorithm being used.  A given modifier might make sense for the join algorithm but not the where-in algorithm due to the columns that are referenced.  I also find myself liberally sprinkling tableRefFor() in these modifiers in order to avoid column name conflicts and make the modifier more generic for use with different eager algorithms.  Really not sure how to approach this, but it's something I run into regularly.

Conflict between jsonb and join alias separator
While there's fantastic support for both jsonb and joins, we currently use : as a separator for both, which sometimes leads to funky workarounds like overriding the separator in defaultEagerOptions.

Consider standardizing validators to implement tableMetadata()
More often than not our validations directly inform table metadata, and I think if there were a blessed way for validators to implement tableMetadata() (and the built-in ajv validator providing this option), then we could remove this rare instance that we rely on some stateful magic.  This might also lead to nice things like the often-desired ability to "select all columns but x, y, z."

Make relation and unrelation more ergonomic
Typically relate() and unrelate() chain off of a model instance's $relatedQuery(), which means that one has to obtain a model instance to use these methods.  I've used workarounds that look like this.  There are a few different directions to explore to alleviate this, but I think there could be some really interesting options to make relatedQuery() more active, and not necessarily relegated solely to subqueries.
// Fetch
await Person.query().findById(1)
    .relatedQuery('pets').where('name', 'Fluffy');

// Unrelate
await Person.query().findById(1)
    .relatedQuery('pets').findById(42)
 .unrelate();

Consider folding objection-db-errors into core
I can only echo my colleague: https://github.com/Vincit/objection.js/issues/1302#issuecomment-484692000.  We use this all the time and it's a better error-handling experience!

Focus on tooling and plugins
This is partly on the community too, but I would love to see more quality plugins appear, especially for modeling common application features.  @faustbrian has done a neat job with this in the Laravel community.  Imagine plugins like "taggable", "commentable", "followable", "likeable", etc.  Objection v2.0 may be able to help by considering how validation works in some of these complex cases, i.e. when a community plugin needs to play nice with existing models that may use one of several validators (we use a joi validator rather than ajv, for example).  On the topic of tooling, generating knex migrations from objection models/validators is also of interest.

@fer22f

In a way, you're right. But I don't like how migrations separate the creation of tables from the Model object itself. It's perhaps a bit more cumbersome, but it's sure convenient!

You should never ever change the migrations, so whether you define your migrations in the model or in a folder of files (like knex migrations) you must always create a new migration in order for them to work (by definition). If you maintain two functions up and down in your model, it's a massive antipattern and not a migration at all. You cannot change the schema without wiping out the entire database. Migrations are separated for this exact reason.

You should never ever change the migrations, so whether you define your migrations in the model or in a folder of files (like knex migrations) you must always create a new migration in order for them to work (by definition). If you maintain two functions up and down in your model, it's a massive antipattern and not a migration at all. You cannot change the schema without wiping out the entire database. Migrations are separated for this exact reason.

You're right. There is only one use case for this: You can be absolutely certain that the database schema matches the one you defined, with migrations, it's quite hard to tell, the easy route is to query the current state of the DB just after you migrated it all.
I often work with renames, adding and removing new columns, in order to deal with a legacy system and extend its behavior. With the custom up and down information, I can generate a graph like this from my database using just the code:

But I'll admit I took I rather counter intuitive approach. Ideally, I would like to be able to type field information in my models, and generate migrations based on the changes I've made (renamed, changed type, etc).

@devinivy Thanks! You have alot of great ideas there.

Passing arguments to modifiers

This will be fixed at least for the modify function's part. I'd like allow arguments for modifiers in relation expressions too. Once modify is fixed for named modifiers, you can at least do this:
class Pet extends Model {
  static get modifiers() {
    return {
      onlySpecies: (query, species) => query.where('species', species)
    }
  }
}

Person
  .query()
  .eager('[pets, children.pets(onlyDogs)]', {
    onlyDogs: query => query.modify('onlySpecies', 'dogs')
  })

That's still pretty verbose, but it allows you to "bind" arguments to existing modifiers. What do you think? Could that be enough? Another option would be a mechanism like this:
Person
  .query()
  .eager('[pets, children.pets(onlyDogs)]')
  .bindModifier('onlySpecies', 'onlyDogs', 'dogs')

but is that really better? It intruduces yet another concept. @devinivy Do you have any other ideas for this?
I've also thought about making modifiers query-wide, so that they could be used with joinRelation etc. So instead of this
Person
  .query()
  .eager('[pets, children.pets(onlyDogs)]', {
    onlyDogs: query => query.modify('onlySpecies', 'dogs')
  })

you'd say this:
Person
  .query()
  .eager('[pets, children.pets(onlyDogs)]'),
  .modifiers({
    onlyDogs: query => query.modify('onlySpecies', 'dogs')
  })

Relation modifiers coupled to eager algorithm

This is a tricky one. I also hate that this happens. That's one of the reasons why I'll deprecate the defaultEagerAlgorithm and eagerAlgorithm() proerties and methods. You need to explicitly use withGraphFetched or withGraphJoined to make it clearer that you are using a completely different algorithm.
Fixing this would again require objection to duplicate the knex API which I've been trying to avoid. We would need to wrap all where*, groupBy, join* etc. methods, parse the inputs and basically build an AST tree to be able to figure out what the user means when he/she uses column name in a query. Is it from a joined table? Is it from a parent query in a subquery situation? The MVP solution would be to wrap all where methods and automatically add ${tableRefFor(modelClass)}.column for each column that doesn't have an explicit table, but that would already require objection to duplicate and test the where API of knex.
If you have any good ideas, I'm all ears.

Conflict between jsonb and join alias separator

This is another complete design flaw I'll be addressing. We can use -> as a separator for either the json references or the joinEager aliases. Which one would you prefer?

Consider standardizing validators to implement tableMetadata()

The Validator API is bad. This is a good idea, but overriding validators doesn't seem to be that common, so I'll probably leave this for later (3.0?) unless you'd like to take a stab at this problem @devinivy? You guys have probably written the most comprehensive custom validator in schwifty.

Make relation and unrelation more ergonomic

// Fetch
await Person.query().findById(1)
    .relatedQuery('pets').where('name', 'Fluffy');

// Unrelate
await Person.query().findById(1)
    .relatedQuery('pets').findById(42)
    .unrelate();

I agree with the title, but not with either of these examples. They would be confusing. The .relatedQuery('pets') in those calls completely changes the query. a where call before that affects the parent query, while where after it affects the "child" query. I'd rather just make creating model instances from just a  relation property (primary key most of the time) easier. Something like this:
await Person.fromId(1).$relatedQuery('pets').where('name', 'Fluffy');
await Person.fromId(1).$relatedQuery('pets').findById(42).unrelate()

Consider folding objection-db-errors into core

Will be done. This was also brought up by @heisian

Focus on tooling and plugins

This is pretty vague. I'd like to see more plugins and 3rd party tools, but I don't know how to help there. The Validator interface is one thing, but I don't think that is the biggest limiting factor right now.

It's only a small feature, but how about a method called $loadRelatedUnlessLoaded, which is like Model#$loadRelated but doesn't load any data which is already in the object.
To see why this is useful, consider the following function.
async function f(user) {
  const u = user.$clone;
  await u.$loadRelatedUnlessLoaded('favouriteBook.author');
  // Do something with u.favouriteBook.author
}

I want to be able to pass a User object to f without having to care about which relations have been loaded.  But if I call $loadRelated in f, then the application is doing unnecessary work if the data has already been loaded.
$loadRelatedUnlessLoaded may not be a good name; feel free to think of a better one.

@phormio That's a good idea :+1:  That has been requested before.
$loadRelated will be replaced by $fetchGraph in 2.0 (the old name will remain at least until 3.0). $fetchGraph will take an options object as the second argument. We can add an option for this. Something like
await u.$fetchGraph('favoriteBook.author', { reloadExisting: false })

@koskimas thanks for the thoughtful response 🙏

Passing arguments to modifiers

I like the example you gave, and I think that's totally fine!  I like the bindModifiers() helper too :) Not a huge fan of the query-wide eager modifiers but also not so hard against it, especially if the current interface remains in existence.

Relation modifiers coupled to eager algorithm

I agree, I think this is a really hard problem to solve and it's not easy to justify the effort.  Going down that path would generate a lot of questions that I don't have answers to.  I would be afraid of making the generated queries harder to control and more opaque.  Making tableRefFor() more friendly sounds like it's low-hanging fruit, and would be a nice improvement.  I would be happy to contribute a section to the docs that addresses this—I get the sense that a lot of people run into this issue then avoid it rather than solve it since tableRefFor() doesn't have a lot of visibility in the docs.

Conflict between jsonb and join alias separator

Would -> make a better separator for jsonb or joinEager aliases?  Hmm... that's hard for me to say.  I struggle with the idea of using that as a separator since it's so close in meaning to postgres's own jsonb operator.  If I had to choose one, I think I would suggest using it for jsonb.  Is ~> too weird?  I don't have a full understanding of knex's limitations here, but another option might be to see what it would take to loosen those limitations in knex.

Consider standardizing validators to implement tableMetadata()

I'll look into it!

Make relation and unrelation more ergonomic

Fair!  I don't think these two options are mutually exclusive, and the example you gave is totally straightforward / would be a nice improvement.    It works, but it doesn't seem super objection-y (obviously this is just a matter of opinion—whatever you decide is "objection-y" by definition!) .  I still think an API similar to what I proposed would be in the spirit of objection as it relates to query laziness and composability.  Does it seem more reasonable if it's re-written in steps?
/* select * from users where type = 'musician'; */
const musicians = User.query().where('type', 'musician');

/* select * from animals where
     type = 'dog';
     "ownerId" in (select "ownerId" from users where type = 'musician') */
const musiciansDogs = musicians.relatedQuery('pets').where('type', 'dog');

/* update animals set "ownerId" = null where
     type = 'dog' and
     "ownerId" in (select "ownerId" from users where type = 'musician') */
const unrelateMusiciansFromDogs = musiciansDogs.unrelate();

// An alternative idea, just for fun.

const musicians = User.query().where('type', 'musician');
const musiciansDogs = User.relatedQuery('pets').per(musicians).where('type', 'dog');
const unrelateMusiciansFromDogs = musiciansDogs.unrelate();

Consider folding objection-db-errors into core

👍

Focus on tooling and plugins

Agree I was pretty vague there.  I'm mostly trying to think of things that could fragment efforts to write generic tooling for objection, so that they can be squashed proactively in v2.  Maybe there's not a lot in the way!

It's only a small feature, but how about a method called $loadRelatedUnlessLoaded, which is like Model#$loadRelated but doesn't load any data which is already in the object.
To see why this is useful, consider the following function.
async function f(user) {
  const u = user.$clone();
  await u.$loadRelatedUnlessLoaded('favouriteBook.author');
  // Do something with u.favouriteBook.author
}

I want to be able to pass a User object to f without having to care about which relations have been loaded. But if I call $loadRelated in f, then the application is doing unnecessary work if the data has already been loaded.
$loadRelatedUnlessLoaded may not be a good name; feel free to think of a better one.

This would be such a useful feature to have and reduce many unneeded queries!

@caiquecastro That's a good idea. @phormio Could you create a separate issue about that feature? That's something we can add after 2.0 since it's not breaking.

@koskimas, I was actually quite happy with your own suggestion.  However, I've opened a new issue asking for Model#$loadRelatedUnlessLoaded.

A small list I can think about to upvote some suggestions:

add db-errors to core. Super useful library a lot of users will appreciate
move to using native stuff, e.g. Bluebird -> Promise, lodash -> native functions, etc. This is already in todo list
drop node 6 support, use >= 8. Seems to be done from todo list
validation feels weird. I had an issue with nested models (https://github.com/Vincit/objection.js/issues/478), moved to validation outside of objection. Maybe something has changed, but this was an issue. I also use another validation library (yup)

This is probably all I can think about, objection gives a joy using database and I'll recommend using it instead of other orms any day. Thank you for it ❤

What about setting useLimitInFirst to true by default, any downsides/cons? 🤔

@vladshcherbin That's a good idea! I'll add that to the 2.0 TODO list.

I am expecting model instance's ability to detect changes, and provides a save() method which internally calls patch() to write changed properties to database.
I have been using ObjectionJS for Anemic model and it's going well. Now I am implementing Domain-driven model following "Backed By a State Object" pattern suggested by Vaughn Vernon - author of popular DDD books. I am too lazy to switch to Sequelize ORM in one microservice while the rest are still using Objection.

@hirikarate Sorry, but that will never be added to objection. If you want an ORM like that, objection is probably a very bad match for you.

Hi, I am going to need the following for a project :-
Objection / knex / PostgreSQL support for :-
- Arrays https://www.postgresql.org/docs/9.5/arrays.html
- Types https://www.postgresql.org/docs/9.5/rowtypes.html
- ROW Security Policies https://www.postgresql.org/docs/9.5/ddl-rowsecurity.html https://www.postgresql.org/docs/9.5/sql-createpolicy.html
That's my wish list ;)

With objection-graphql to be able to output/generate a user editable GraphQL Schema and resolver code from a Objection database, so resolvers can be hand modified. And even better still some form of user templating in the generation !

Remove Bluebird dependency in favor of native Promise! If you check the composition of objection, Bluebird is not a trivial contributor<EMAIL_ADDRESS>

Moving to JavaScript native Promises is a must !

@AaronNGray @dustinnewman98 Bluebird is already removed in the v2.0 branch.

And so is lodash by the way.

I've been using Objection on small personal projects lately and it's been amazing. One thing I've looked for in the documentation and issues but I haven't been able to tell if it's possible or not is to pass a transaction to a hook?
I use Sequelize daily at work (I personally enjoy Objection more 😉) and I've had a few cases where I created a transaction for doing an insert, I also had an afterCreate hook on the model that did some async action, if the async action in the afterCreate threw an error it would roll back the creation. This page on hooks under the "A Note About Transactions" has some of the relevant documentation.
After looking at the Objection documentation I understand that I could make some custom query method and do the transaction and all the async stuff in there so that's an option too.

Is there a way to turn off hooks? For example in Sequelize you can pass a { hooks: false } to not trigger the hooks attached to a model?

I understand that the goal of Objection is to be small and lightweight and not be everything to everyone. I also know that these questions are kind of small/niche so I completely get if these aren't on the roadmap for v2 or won't ever be on the roadmap. I thought I would ask just to see though. Thanks!

TL;DR; Maybe a way to generate jsonSchema from the state of a database table?
I've been using Objection for a couple of months now and have largely been pretty happy with it. My primary previous ORM experience has been with the Django ORM (written in Python).
One thing I've noticed that can be tough in a team setting is having a quick way to see all the properties of a Model. In something like Django, the Model is defined first (akin to Objection's optional jsonSchema) and then the migrations are derived from that; so you always have an up-to-date reference for what is available on a model. But with Objection, jsonSchema is optional and not intrinsically tied to the underlying data store, so if you don't try and keep it up-to-date (or don't define it at all) it's very hard to quickly tell what is available for a model without perusing every migration that involved the underlying database table.
I don't really know any options to resolve this other than "try to keep jsonSchema maintained for every model". I'd love to hear suggestions from others if there are any.

@leeallen337 The transaction is already passed to the hooks as the transaction property of the context argument.

Postgre JSONB operators support. Like jsonb_set and such. Although this might be better addressed at knex level.

@capaj

Postgre JSONB operators support. Like jsonb_set and such. Although this might be better addressed at knex level.

jsonb_set is already handled by .update and FieldExpression or what kind of use-case you were thinking of? Last example in https://vincit.github.io/objection.js/api/query-builder/mutate-methods.html#update is actually using jsonb_set to update value inside json column and with FieldExpression you can refer / cast any attribute inside jsonb column.

@elhigu oh wow! I had no idea objection has this supported already! That is awesome.

filtering relationJoins. Something like how knex joins do it.

knex.select('*').from('users').join('accounts', function() {
  this.on('accounts.id', '=', 'users.account_id').orOn('accounts.owner_id', '=', 'users.id')
})
Outputs:
select * from "users" inner join "accounts" on "accounts"."id" = "users"."account_id" or "accounts"."owner_id" = "users"."

I'd like to see .insert() support bulk insert for DBs other than Postgres. Objection is built on top of knex, and by looking at one of my knex seed files it's very apparent that knex can handle bulk insert for DBs like SQLite...
exports.seed = knex => {
  return knex('todo').insert([
    {
      title: 'Pickup dry cleaning',
      complete: false,
      note: 'They close at 7pm',
      due_date: '2019-11-10 08:30:00',
      priority: 'low',
      category_id: 1
    },
    {
      title: 'Create meeting agenda',
      complete: false,
      note: 'See Jeff\'s email from 8/15',
      due_date: null,
      priority: 'medium',
      category_id: 2
    },
    {
      title: 'Finish math homework',
      complete: false,
      note: 'Only the even problems',
      due_date: '2019-12-15 10:15:00',
      priority: 'high',
      category_id: 3
    }
  ])
}

@johncmunson There are a number of issues about that. postgres is the only db that returns the identifiers of all inserted rows (a requirement of objection) in case of a bulk insert. On all other databases we would need to run multiple separate inserts under the hood. The insert method should be kept as an equivalent of the SQL operation and it should not start multiple queries.
You can already use insertGraph to do bulk inserts, but remember to use allowInsert if you insert user provided data directly.
We could add a separate insertArray method or something.

Gotcha, thanks for the great explanation and alternative solutions.
To go along with that, I'm assuming that similar logic as described above is also why objection provides .delete() and .deleteById(), but .patch() and .update() do not have corresponding ById() methods?

Also, something you may want to call attention to in the documentation for .update() and .updateAndFetchById() is the fact that these methods aren't on their own behaving like a RESTful PUT. This may catch some people off guard. To further explain, here's the comment I left to myself above my PUT /todos/:id route...

.update() and .updateAndFetchById() are not on their own behaving like a RESTful PUT should. A PUT should entirely replace the existing resource. If there's an existing todo item with id = 4 and note = 'lorem ipsum', if I do a PUT to this resource with only the required properties (i.e. no note), then the note should now be set to null, but .update() is allowing it to keep it's old value.

The update is acting like a restful put. You are mistaking undefined and null values here. No version/explanation of REST I've ever read has stated that missing values should be treated as null. I think most people would find it odd if they were.
patchById(id, obj) and updateById(id, obj) are missing because i think findById(id).patch(obj) is cleaner. I try to avoid methods that take multiple arguments. updateAndFetchById(id, obj) exists because it cannot be replaced by a single query. deleteById is also a bit redundant, but that's already there.

Sorry, but I'm deleting comments that are not feature requests to keep this issue redable. Feel free to open separate issues.

I have two main things now:

Have a way to marshall types, in and out: I want to use js-joda, and big.js. It would be nice to be able to transform values before going to the database driver, and when it comes back (perhaps it could even be advanced to the point of issuing automatic cast(as string) mappings, but that would too good).

Why?  Tedious/MSSQL doesn't have a solution for this. Postgres has a parsing solution, but no encoding solution. SQLite has nothing. Dealing with dates and decimal values is error-prone without some support for this. Typeorm has a transformer option, but supports poorly complex types like js-joda's (anything with a recursive object, really).

Filter inside relations. Now this plagues all my codebase. This is the reason I use joinEager, because I can where child values, and if there aren't any child values present, the parent value doesn't show up, this is awesome, but is not very versatile.

More support for the data mapper pattern. We could get rid of extends Model. We could get rid of calling .query() on the model itself, and having methods at all in the Model. What we have currently is much more like ActiveRecord, and when we need to use a transaction, we need to query(trx) (and never forget it). Our multitenancy pattern is also weak in this regard, instead we could issue a query builder with a model, not a query builder from a model, making it more composable.

Support for nested transactions with soft transactions (maybe?), support for multiple transactions running at the same time with a connection pool.  But this can be more easily circumvented (by having slower software).

Have a way to marshall types, in and out: I want to use js-joda, and big.js. It would be nice to be able to transform values before going to the database driver, and when it comes back (perhaps it could even be advanced to the point of issuing automatic cast(as string) mappings, but that would too good).

You can already do this. See the hook docs.

Filter inside relations. Now this plagues all my codebase. This is the reason I use joinEager, because I can where child values, and if there aren't any child values present, the parent value doesn't show up, this is awesome, but is not very versatile.

There is no way to do this with the normal eager/withGraphFetched. It's impossible. You need to use joinEager/withGraphJoined or subqueries. In addition to the examples behind the link, you can pass those relation subqueries virtually everywhere.

More support for the data mapper pattern.

Not going to happen :smile: All the issues listed here can easily be solved in other "objectiony" ways. Objection is not any other ORM, nor does it try to mimic them just because they are popular.

Support for nested transactions with soft transactions (maybe?), support for multiple transactions running at the same time with a connection pool.  But this can be more easily circumvented (by having slower software).

Already supported. Simply use knex's way to nesting transactions or trx.raw.

Answer by @elhigu (an active knex maintainer)

Postgres has a parsing solution, but no encoding solution.

I just wanted to point out that pg driver actually does have encoding solution for incoming data that can be overridden. Most simple way to use it is to add function .toPostgres to your object for serialization.  https://github.com/brianc/node-postgres/blob/master/lib/utils.js#L45
Anyways it is true that there is no common way for all databases to do that and it could probably be implemented as a objection.js plugin since there are already lifecycle methods where mappers could be called.

What we have currently is much more like ActiveRecord

“The active record pattern is an approach to accessing data in a database. A database table or view is wrapped into a class. Thus, an object instance is tied to a single row in the table. After creation of an object, a new row is added to the table upon save. Any object loaded gets its information from the database. When an object is updated the corresponding row in the table is also updated. The wrapper class implements accessor methods or properties for each column in the table or view.”

Objection is a bit like active record in a sense that class presents a table and instance a row, but objection does not create or update object back to database that way (and it has been design decision from the start to prevent having too much magic going on behind the scenes with caching and tracking changes in model attributes).

Support for nested transactions with soft transactions (maybe?), support for multiple transactions running at the same time with a connection pool.

Knex supports nested transactions through single connection and they have been implemented by using save points. So objection supports them too. Multiple transactions in same pool work also just fine.

We could get rid of calling .query() on the model itself, and having methods at all in the Model. What we have currently is much more like ActiveRecord, and when we need to use a transaction, we need to query(trx) (and never forget it).

If you don't bind base Model to any knex instance, then you can use models in a multitenant way. In my own projects I never use global binding to single knex instance, but always give knex to .query(knex) when doing queries. That way you can also easily decide if you want to choose to send query to some read replicas instead of master. That also prevents the errors where you forget to pass trx parameter to queries which should go to specific transaction (if you await just .query() it will throw an error).

Ok, neat, thanks for the response!

There is no way to do this with the normal eager/withGraphFetched. It's impossible. You need to use joinEager/withGraphJoined or subqueries. In addition to the examples behind the link, you can pass those relation subqueries virtually everywhere.

Yea, this is a bit sad, but these subqueries do seem very nice, I could rewrite my stuff to use EXISTS instead of joining, I think this could probably work.

You can already do this. See the hook docs.

Awesome. Maybe collect up a recipe for it? But I will definitely explore this a little more :)

Not going to happen 😄 All the issues listed here can easily be solved in other "objectiony" ways. Objection is not any other ORM, nor does it try to mimic them just because they are popular.
If you don't bind base Model to any knex instance, then you can use models in a multitenant way. In my own projects I never use global binding to single knex instance, but always give knex to .query(knex) when doing queries. That way you can also easily decide if you want to choose to send query to some read replicas instead of master. That also prevents the errors where you forget to pass trx parameter to queries which should go to specific transaction (if you await just .query() it will throw an error).

Ok, this seems like a good solution to the problem. You should always pass a knex object, it doesn't come with a query builder built-in.

I just wanted to point out that pg driver actually does have encoding solution for incoming data that can be overridden. Most simple way to use it is to add function .toPostgres to your object for serialization. https://github.com/brianc/node-postgres/blob/master/lib/utils.js#L45

My fault, I currently use this and mispoke. Although I think changing .prototype of library objects is not a good idea overall (but I do it), and doesn't work across modules (it's a bit of a weird global coupling).

You can already do this. See the hook docs.

I can do this with models, but not with where, I suppose. But it's a good start. One example:
      .where(
        ref("updateInstant").castTo("date"),
        myLocalDate.toString()
      )

I would like to see in next version of Objection is conditinal clauses like in Laravel Eloquent https://laravel.com/docs/7.x/queries#conditional-clauses
This feature will avoid to use if/switch expressions in light queries, like:
const searchBooks = (year, searchTerm) => Books
.query()
.when(searchTerm.length, qb => qb.where('title', 'like', `%${searchTerm}%`)
.when(year !== undefined, qb => qb.where('year', '>=', year)
.orderBy('id', 'DESC')
.page(0, 100)

@asergey87 : you could already use a custom QueryBuilder that adds conditions like:
export default class ExtendedQueryBuilder extends QueryBuilder {
  if(test, fnif, fnelse) {
    return test ? fnif(this) : (fnelse ? fnelse(this) : this);
  }

  ifClient(name, ...args) {
    const not = name[0] === '!';
    if(not) {
      name = name.slice(1);
    }
    return this.if(!!(not ^ (this.knex().client.config.client === name)), ...args);
  }
})

It would be nice to have the option to leverage the ES6 named export syntax, now that Node 14 supports ESM without the experimental flag.
This:
import { Model, QueryBuilder } from 'objection'

is much nicer than:
import objection from 'objection'

const { Model, QueryBuilder } = objection

Hey just chiming in, I saw some talks about unrelate and wanted to give this insight too:

with a many to many relation
I used user.$relatedQuery("teams").relate(teamId); and it felt natural
Then I tried user.$relatedQuery("teams").unrelate(teamId); and it failed telling me to use some where clause. Which felt weird because I thought it would have just worked like relate

Maybe there are challenges in making this more symmetrical, if so we could explain it in the doc if that's something we can't change.
Thanks!

@vvo I second this, unrelate previously worked the way you expected, but it was changed later for some reason. Wondering if there is some limitation so the old syntax can't be supported now.
While working with m2m relations without graphs I'd be happy to have sync function where you pass relation ids and it would insert/delete current relations according to passed ones. However, this's a topic of a separate feature request.

@vvo Unrelate follows the same logic as delete and it is in fact a delete in case of many to many relationships. You can do stuff like this:
user.$relatedQuery('teams').unrelate().where('team.members', '<', 10)

or use whatever SQL query you want. You wouldn't be able to do that if we changed the API to take an id.

@koskimas Thanks for the explanation, I think if we were to do something it would be about making relate and unrelate similar in usage.

or use whatever SQL query you want. You wouldn't be able to do that if we changed the API to take an id.

I must be missing some challenges about why relate(id) is ok but unrelate(id) is not ok (besides the current implementation that does not accept it)? Can't we express in current code "If unrelate is called with a parameter, then it's a 'unrelateById' call"?
Whatever we make, if relate can be called relate(id) and unrelate can't then it will always come as a suprise to a developer building API routes like:

add user to team, let's use relate(id)
remove user from team, let's use unrelate(id), woops does not works!

I re-read your answer and understands the current unrelate() goes beyond just removing user from a team (thanks to where etc..) but I am not sure to understand why we could not have the best of both worlds :D

Because having two ways to do one thing is confusing. As I said, I can add unrelateById method that would work the way you want. You don't seem to complain about how delete works? The exact same arguments on both sides apply to the delete method.

@koskimas

await user.$relatedQuery('teams').unrelate()
await user.$relatedQuery('teams').relate(newIds)

Yeah, this does the job. However I'd expect this -sync method selects all relations, grabs their ids, matches with provided ids and accordingly runs insert ids, delete ids.
I believe upsertGraph example could also work, but I was so turned away after seeing a huge warning in docs about using it only it if you can't use simple methods because of complexity, problems, etc. After reading this I quickly switched to relate, unrelate and was also surprised to see an error after using unrelate(ids).
Then I had this case where I needed to compare existing and provided ids and relate/unrelate accordingly. I quickly checked if there is an easy way to do this, didn't find one except upsertGraph with scary warning and checked how it's done in laravel docs (even after years I'm amazed by its architecture). Found there methods:
$user->roles()->attach($roleId);
$user->roles()->detach($roleId);
$user->roles()->sync([1, 2, 3]);

translate to objection
user.$relatedQuery('roles').relate(roleId)
user.$relatedQuery('roles').unrelate(roleId)
user.$relatedQuery('roles').sync([1, 2, 3])

Looks so natural and simple to me, wondering on your thoughts about actually having this.

Because having two ways to do one thing is confusing.
Definitely agree on this for APIs, always confusing: which way to choose

But I am convinced that if you have an API method like deleteFile(path) and you have undeleteFile().where("path", path) then the developer experience is not usual. The natural way someone would try to use undeleteFile() would be undeleteFile(path), it seems obvious from the user perspective. If the method are named the same with just the addition of "un" then people will try what I tried. The symmetry of the API here seems important given the names relate/unrelate.
If unrelate was not an API method I would not even complain: I am fine using another way, but since the method is here, I tried to use it the same way I used relate().
I will stop here trying to push for this and say: I always enjoy working with objection.js and wanted to provide you this feedback about unrelate.
About delete: I did not encounter a case where I was surprised by the API but if I ever encounter such case I will make sure to always give you the feedback!
Good luck! And thanks for the library again.

I think the main thing that is getting lost here is that objection is a query-builder, so the semantics of the API is fairly one-to-one with the queries that it is generating.  Just as the semantics of SQL's INSERT and DELETE are not symmetrical, objection's relate() and unrelate() are not symmetrical.

I'm hiding these comments to keep this thread readable. Let's move further discussion elsewhere. Feel free to open separate issues. @vvo @vladshcherbin

Not a specific request, but after using Objection for a couple months I feel like the API offers too many ways to do the same thing. For example, I'm currently trying to figure out the difference between fetchGraph and withGraphFetched, and why would I choose one over the other.
If Objection intentionally provides several different approaches to ORM, it would be nice to make this explicit. Otherwise I'd very much like to see as many methods as possible deprecated.

@Kinrany I disagree. The difference between these two is pretty clear.

fetchGraph is used on an instance of a model. So you'd use it when you have fetched something from a table, but for some reason you need to fetch additional data via relations.
withGraphFetched is on QueryBuilder. You use that if you know upfront that you will need data from those relations.

Maybe this is more on knex level but I would love to see something like the Sandbox Adapter from ecto (https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html).
This allows for pretty painless and fast integration tests.

q.where(ref('data:prop.list').arrayLength())

@koskimas
I would like to see a section which run micro query directly from query param of API calls.
I have created a patter for micro query -> then I need to convert this patter to raw query and finally use objection object .whereRaw() to execute the same.

Change the api for $fetchGraph. At the moment it accepts an option {skipFetched: true}.
I would very much prefer if it instead by default behaved like when {skipFetched: true} and to force refetch of related items, you would use a different method-could be something like
$fetchGraphForce()
To me seeing a code with a different method name is more explicit that the opt object.
IMHO in general usecase where you use objection on an API, you typically don't need to always refetch.

Change the api for $fetchGraph. At the moment it accepts an option {skipFetched: true}.
I would very much prefer if it instead by default behaved like when {skipFetched: true} and to force refetch of related items, you would use a different method-could be something like
$fetchGraphForce('user')
To me seeing a code with a different method name is more explicit than the opt object.
IMHO in general usecase where you use objection on an API, you typically don't need to always refetch.

Thank you… will surely look into this… 😊


Error installing less

sudo npm install less
npm ERR! Failed unpacking /tmp/npm-1318268718731/1318268718731-0.12470442149788141/tmp.tgz
npm ERR! couldn't unpack /tmp/npm-1318268718731/1318268718731-0.12470442149788141/tmp.tgz to /tmp/npm-1318268718731/1318268718731-0.12470442149788141/contents
<EMAIL_ADDRESS>./node_modules/less
node --version: v0.4.12
npm --version: 1.0.94
tar --version: bsdtar 2.8.3
mac osx 10.7.1

Where's the rest of the output?

That was it. All it spit out was two ERR! lines.
However, just prior to getting the notification of your reply, I got the install to work. Apparently it matters where I'm sitting in my terminal when I run the install. I had been looking through the guts of the npm install prior to installing less. So I was actually in the /usr/local/lib/node_modules/npm/bin directory when I executed the sudo npm install less command.
When I returned to ~ and ran the command, it installed with no issue.
Sorry for the false alarm.

Yes, npm installs things locally.  Run npm faq and read what it says :)

Will do. Much obliged for the prompt reply.


Can install<EMAIL_ADDRESS>on a Macbook with M1 chip

Steps to reproduce
Simple when trying to Install<EMAIL_ADDRESS>such as "npm install<EMAIL_ADDRESS>in an empty project on an M1 MacBook you get this error:
`npm install<EMAIL_ADDRESS>npm ERR! code 1
npm ERR! path /Users/patrick/Code/node_modules/puppeteer
npm ERR! command failed
npm ERR! command sh -c node install.js
npm ERR! The chromium binary is not available for arm64:`
Tell us about your environment:

Puppeteer version: 5.5.0
Platform / OS version:  macos
URLs (if applicable):
Node.js version: Node 14 and 15 with nvm.

What steps will reproduce the problem?
Please include code that reproduces the issue.
1.npm install<EMAIL_ADDRESS>2.
3.
 The chromium binary is not available for arm64:`

https://stackoverflow.com/questions/65928783/puppeteer5-5-0-install-node-install-js-on-m1


Add constants for common amqp exchange types

It would be useful for library users to deal with constant values instead of raw strings
when choosing the exchange type. It can help to avoid mistakes which are very simple to do with plain string.
For example net/http package from the standard library uses the same approach for HTTP statuses and methods and it is pretty useful: https://golang.org/pkg/net/http/#pkg-constants.

Thank you!


Added support for NetStandard15 and changed to VS2017

from https://github.com/richclement/NLog.Redis/pull/7

todo: needs update appveyor config

Not sure what I should check. Not using Redis
Sent from my Sony Xperia
---- Julian Verdurmen wrote ----
@snakefoothttps://github.com/snakefoot maybe time to check this? #2https://github.com/NLog/NLog.Redis/issues/2
I think the testproject isn't converted yet.
thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/NLog/NLog.Redis/pull/1#issuecomment-427998391, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AK-fnBLH7-ffd4Pgl9sNxWmhpN6UhHKxks5ui9CjgaJpZM4WfnxH.

The main project is converted to <Project Sdk="Microsoft.NET.Sdk"> (thanks for that), but https://github.com/NLog/NLog.Redis/blob/master/src/NLog.Redis.Tests/NLog.Redis.Tests.csproj isn't and we have build issues, so maybe that's related?


Update Python path to reflect changes in macOS 12.3+

As of macOS Monterey 12.3, the version of Python 2 that shipped with macOS located at /usr/bin/python has been removed. More context can be found in some posts from Mac admins at the beginning of 2022, aggregated here.
Since version 2.0.2, AutoPkg's installer has included its own Python 3 framework, symlinked from /usr/local/autopkg/python. Similarly, Munki ships with its own Python 3 framework, symlinked from /usr/local/munki/munki-python. This pull request adjusts the shebang and interpreter paths of processors, pre/post install scripts, and other files to replace /usr/bin/python with the AutoPkg or Munki Python 3 symlinks as appropriate.
NOTE: Because AutoPkg processors are imported as modules by AutoPkg and not executed directly, processors' shebang has no effect in normal usage. However: (a) some people execute processors directly during testing, and these tests won't work unless the shebang points to a valid Python 3, and (b) having instances of /usr/bin/python in the codebase could lead to confusion for people not deeply familiar with processor behavior.

Disregard — I'll open another PR without the Python autoformatting, for minimal diffs.

Hey Elliot,
Thanks.  I have been slowing going through my Processors and updating the shebang along with some other standardization/cleanup stuff.
I appreciate it either way.


Infinite loading after putting the password and hit Log in

After a unexpected shutdown, the node gets stuck in login, however I can login via SSH.
What can I do? Any troubleshooting?
Thanks.

Closed due to inactivity, let us know on https://community.getumbrel.com if the issue still exists - it would be helpful for us to see the debug logs if this is still happening, thanks!


Ftx namespace changes to processors

This PR fixes #87
Description of changes
With reference to changes merged through Forte in PR, we updated the ontology namespace structure. The processors in Forte-wrapper needed to incorporate those updated namespaces. Only SpacyProcessor works with the ftx folder, hence that's the only file that has been updated.
Possible influences of this PR.
Code shouldn't throw Import errors now.

Sounds good, let’s address this in another. We can merge this after we fix
the mypy runs tomorrow
On Tue, Mar 1, 2022 at 10:02 PM Piyush Yadav @.***>
wrote:

@.**** commented on this pull request.
In src/spacy/fortex/spacy/spacy_processors.py
https://github.com/asyml/forte-wrappers/pull/89#discussion_r817309296:

@@ -28,7 +28,7 @@
from forte.data.ontology import Annotation
from forte.processors.base import PackProcessor, FixedSizeBatchProcessor
from ft.onto.base_ontology import EntityMention, Sentence, Token, Dependency
-from ftx.medical.clinical import MedicalEntityMention, UMLSConceptLink
+from ftx.onto.clinical import MedicalEntityMention, UMLSConceptLink

Got it, I was looking at pretrained_encoder_processor.py but this example
is a better one since we will need to set attributes of the class instances.
I will be making changes to SpacyProcessor pertaining to this, since we
will need to pass both MedicalEntityMention and UMLSConceptLink through
config. I am thinking we should have a new issue (which better explains the
problem) and PR for this? This particular PR can be pushed as is.
—
Reply to this email directly, view it on GitHub
https://github.com/asyml/forte-wrappers/pull/89#discussion_r817309296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHYBNZ2BCCRNMLXGKW54CLU53K2TANCNFSM5PDLKLOA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

--
Hector, Liu Zhengzhong
Website: https://hunterhector.github.io/
LinkedIn: http://www.linkedin.com/pub/hector-zhengzhong-liu/23/115/406


Holographic Remoting does not fail to connect to device gracefully on OpenXR

Describe the bug
When the user has configured the MRTK for Holographic Remoting but does not have their device running the Holographic Remoting app and presses the Play button, Unity and OpenXR will not handle the failure to connect gracefully. Unity will become unresponsive while the in-editor player is active, but the Play button will respond to being clicked while in this state so it is possible to restore Unity back to a responsive state. Upon the in-editor player stopping, 7 warnings and 1 error are generated for the OpenXR plugin. Their messages are in the screenshots below. This issue does not effect Unity 2019. This issue does effect Unity 2020 with OpenXR via UPM and .unitypackage packages. Eventually all opened Unity 2020 projects with OpenXR will crash after this issue is encountered.
To reproduce
Steps to reproduce the behavior:

Import the MRTK to Unity 2020 via UPM or .unitypackages
Configure MRKT for OpenXR
Configure Holographic Remoting for your HoloLens
Keep your HoloLens powered off or do not load the Holographic Remoting app
Open any example scene and click the Play button
Watch Unity become unresponsive with the example scene running
Click the Play button to stop the in-editor player
Look at the Unity Console for warnings and error

Warnings and Errors
All warnings and error

OpenXR Reprojection warning

OpenXR mesh settings warnings

Connection warning

OpenXR Reprojection warning

Single line console output

Expected Behavior

Your setup (please complete the following information)

Unity Version 2020.3.7f1
MRTK Version 2.7
OpenXR 0.9.5

Target platform (please complete the following information)

UWP
Holographic Remoting

Additional Information
Let the in-editor player run for a few seconds in this state and the "Successful Restart" message will populate in the Unity Console as well.

This looks by-design to me. The remoting feature will continue to attempt to connect until you tell it not to. How would you prefer it to behave otherwise? @elbuhofantasma
All the warnings are also by-design. The idea is that you call the API and it either succeeds or it doesn't depending on the OpenXR feature being supported. All these cases should have appropriate fallback behavior, with the logs being present to let you know specifically why it failed.

This has now been improved on the Mixed Reality OpenXR Plugin side. We now attempt a specific number of retries and then exit play mode automatically if unsuccessful.


Can't create paywall link if title and description are too long

Need to implement character limits.

deployed 🚀

Need to lower character limits. Just found out that the invoice description have a max char length of 200 rather than 250.


Live

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/TOC.md
:white_check_mark:Succeeded

windows-iotcore/connect-your-device/SSH.md
:white_check_mark:Succeeded

windows-iotcore/develop-your-app/IoTCoreDefaultApp.md
:white_check_mark:Succeeded

windows-iotcore/learn-about-hardware/SoCsAndCustomBoards.md
:white_check_mark:Succeeded

windows-iotcore/media/IoTCoreDefaultApp/CommandBar.gif
:white_check_mark:Succeeded

windows-iotcore/release-notes/CurrentCommercial.md
:white_check_mark:Succeeded

windows-iotcore/release-notes/commercial/October2018Update.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Show the contents without open the file at the Find Files feature.

Show the contents without open the file at the Find Files feature.
I think you'll hard to understand my issue..
I've video for you. here is the link.
Very short video (:
http://www.youtube.com/watch?v=OHTfCr9aPfE
Do you have a plan for support this feature?

Yup, this is planned, you can subscribe to https://github.com/atom/atom/issues/3683 to get updates.


Support Libraries Version Mismatch

I'm getting errors on updating AcrUserDialogs, It needs latest Android Support Libraries, and latest Xamarin.Forms nugget isn't compatible with it.
Maybe the version requirement on the nugget shouldn't be pumped, and walks together with the latest Xamarin.Forms requirements?

I can't be held back from updates because of one technology vs another.  I drive these libraries based on my needs and unfortunately, xamarin forms is a very low priority in that scheme.
Use 4.2.1 and ask xamarin to update their stuff accordingly.

I asked both :)
I'm already using 4.2.1 until Xamarin fixes it.
Thanks for the feedback, and for the library!


how to pass header to protomapsL.leafletLayer()

if my .pmtiles file need to header for access how to pass the header

What kind of header is it? You can implement a custom PMTiles source, or https://github.com/protomaps/PMTiles/pull/112 will make this easier in a few weeks

My question is when I am sending  the URl like
const url="https://somename.pmtiles"    //this file can be access by bearer token
var layer = protomapsL.leafletLayer({         url:url ,         paint_rules: PAINT_RULES,       });
is there any option where I can send the token    with the URL

Is the bearer token constant for the entire lifetime of your webpage or do you have to update it?

I need to update it

Then the solution we'll have in https://github.com/protomaps/PMTiles/pull/112 will not work, you will need to create your own implementation Source similar to FetchSource that lives in your code and holds the state of your token, then create a PMTiles instance and pass that into leafletLayer
https://github.com/protomaps/PMTiles/blob/main/js/index.ts#L283

If your token does not change, then you can create a FetchSource and pass in a Headers object; I am planning to implement this in about 2 weeks.

example here: https://github.com/protomaps/protomaps-leaflet/blob/main/examples/pmtiles_headers.html


configuration: add target for VeeR EL2

This allows building Tock applications for VeeR EL2  (see related PR: https://github.com/tock/tock/pull/4118)

From what I see here: https://github.com/tock/libtock-c/blob/master/AppMakefile.mk#L273
The base address I've used (0x80030080) is problematic. The generated linker script (*userland_debug.ld) has a negative value specified for the origin of FLASH:
FLASH (rx) : ORIGIN = -87, LENGTH = PROG_LENGTH

I am able to change the base address, so I'll just change the linkerscript in Tock and the addresses in libtock-c, then respond again here.

Oh I see, this is because we have a long standing assumption that using address 0x80000000 as a fake flash address (for PIC apps) won't conflict with anything. But if app flash does start nearish 0x80000000 then this error happens.

That seems ... problematic. Any immediate / obvious solutions, or is this a good thing to discuss synchronously on the call Friday?

It's not problematic for ARM, which defines the suites of addresses which can be used for memory-like things.

(That said 0x80... — 0x9f... is reserved for SRAM-like structures, "Memory with Write-Through cache attribute." — we probably should change the sentinel value to be something more definitely not a memory, e.g. 0xE0000000-, which is the start of the PPB space, and holds ARM-defined [and immutable address] system configuration registers)

Is there any similar address region defined by the RISC-V spec, which could never for any valid core have memory?

I've adjusted the memory map in the PR to Tock: https://github.com/tock/tock/pull/4118
And also created a related PR to tockloader: https://github.com/tock/tockloader/pull/117
I consider these changes in-sync and ready.
I'm not sure if the CI here failed because of the changes actually, from the log:
2024-08-28T14:00:13.8161250Z 218350K .......... .......... .......... .......... .........  WARNING: Fetching newlib from mirror https://alpha.mirror.svc.schuermann.io/files/tock failed!
2024-08-28T14:00:13.8162450Z . 74% 92.0M 1s
2024-08-28T14:00:13.8163036Z ERROR: Unable to find tock-newlib

Could you please restart the CI or explain how I should handle this?

(n.b., re-running CI job now assuming that was a transient server error)

@lschuermann ^ Looks like something's broken with the newlib files?

Yeah, it's weird that it fails -- it should try both UVA and my server as a mirror, and we can add more if necessary. @wsipak I can't find the logs of this failed workflow but I'd be curious as to whether it tried to fetch something from cs.virgina.edu first and that also failed. In this case, it's more likely to be a local (transient) network issue at the CI host.


[Compose] How to achieve the same "bias" effect as xml

Hi, in Compose, if I arrange 3 Boxes vertically, and the middle Box depends on the upper and lower 2 Boxes:
top.linkTo(box1.bottom)
start.linkTo(parent.start)
end.linkTo(parent.end)
bottom.linkTo(box3.top)

Then if I want to make Box 2 as close as possible to Box 1 or Box 3, this is easy to do in Xml by setting its bias:
<Box app:layout_constraintVertical_bias="0..1" />

But in Compose, the only thing I can find related to the keyword "bias" is ChainStyle.Pack(). Unfortunately Chain overrides Box's original constraints (Although I know that is what is written in the Compose code)

origin
createVerticalChain(box2)
createVerticalChain(box1, box2, box3)

Of course, in alternative way, I can put Box2 in a "FrameLayout" and using its alignment to achieve “bias”. And this FrameLayout replaces the original Box2's position in the ConstraintLayout.

Well this approach is obviously not elegant, I'm wondering if I'm using Chain incorrectly, or if there are other ways to achieve a similar effect

At the moment you'll have to use linkTo(start, end, ..., bias). See ConstrainScope.linkTo.
But since it's not always the most convenient way, we'll make all those parameters available at the property level.

Opps...I almost lost a linkTo method here in [ConstrainScope]. I thought only a Anchorable reference has linkTo method, which has limited parameters:
  fun linkTo(
        anchor: ConstraintLayoutBaseScope.HorizontalAnchor,
        margin: Dp = 0.dp,
        goneMargin: Dp = 0.dp
 )

thanks for reply!


Lookout

Motivation:
Add the lookout module, report the information to lookout.
Modification:
Add lookout module.
A LookoutSubscriber was declared to monitor bolt thread pool status and call information.
Add lookout-api dependency.
Result:
If the "lookout. collect. disable" is false. The call information will be collected and reported to lookout.

lookout has been opened? we need to wait util they published?

@leizhiyuan   yes. I'll push it first, you can review it first.

Abandoned . Resubmit it in #127 .


[BUG]: Field name overwrites join with null [Relationship builder]

What version of drizzle-orm are you using?
0.26.1
What version of drizzle-kit are you using?
0.18.1
Describe the Bug

Have a field inside a table with the same DB-native name as another object

export const users = sqliteTable('users', {
  id: text('id').primaryKey(),
});

export const usersRelations = relations(users, ({ many }) => ({
  tokens: many(tokens),
}));

export const tokens = sqliteTable('tokens', {
  id: integer('id').primaryKey(),
  userId: text('user').notNull(),
  //            ^^^^
  // Notice the field name here
  // This is duplicate with the name below
});

export const tokensRelations = relations(tokens, ({ one }) => ({
  user: one(users, {
// ^^^
// This duplicates the field above
    fields: [tokens.userId],
    references: [users.id],
  }),
}));

Query the Token with the relational query builder:

const dbUser = await request.db.query.tokens.findFirst({
  where: eq(tokens.id, 1),
  with: {
    user: {
//  ^^^^
//  This here is the issue, I assume Drizzle doesn't know which one to
//  query
      columns: {
        id: true,
      },
    },
  },
});

The types for dbUser is the following:
const dbUser: {
    id: number;
    userId: string;
    user: {
        id: string;
        tokenType: string;
        accessToken: string;
    };
} | undefined

but at runtime the type is this:
{
  id: 1,
  userId: '81095245',
  user: null
}

I'm not quite sure why user here is null but renaming the first field in the DB fixed it.
Expected behavior
The object should not contain null at runtime.
Environment & setup
Cloudflare Workers + Cloudflare D1 (SQLite)
Notes
If anyone finds a better title, please suggest / edit it :)

You can't have the relation name be the same as the DB column name.

yeah,  I would agree that this is mostly a documentation issue.

Guys, what is the progress?
Will relationship type have null?
I mean:
const dbUser: {
    id: number;
    userId: string;
    user: {
        id: string;
        tokenType: string;
        accessToken: string;
    } | null; <<<<<<< null here one
} | undefined

I think it should be added for one-to-X relationship, because in a real works it may happen that secondary table does not contain relevant record.


On orientation circle not coming on right place

I want to move selected circle on orientation. which is not happening right now.
https://prnt.sc/rcfxox

and me  , move selected circle on orientation. which is not happening right now.


Location of external psram component

Can somebody show me which component is psram?

The ESP32S3 R8 has the 8MB PSRAM built into it's package. Basically it's a multichip module. So no external RAM on the LilyGo PCB is needed. Take a look at the ESP32S3 dataset page 10. There is an external flash chip on the PCB.
-Steve

The ESP32S3 R8 has the 8MB PSRAM built into it's package. Basically it's a multichip module. So no external RAM on the LilyGo PCB is needed. Take a look at the ESP32S3 dataset page 10. There is an external flash chip on the PCB. -Steve

Thank you!

The ESP32S3 R8 has the 8MB PSRAM built into it's package. Basically it's a multichip module. So no external RAM on the LilyGo PCB is needed. Take a look at the ESP32S3 dataset page 10. There is an external flash chip on the PCB. -Steve

And a question, it is possible to add more psram?

I guess there are two ways to add more RAM. Looking at the ESP32S3 datasheet there is the ESP32-S3R16V version that has 16MB of in-package PSRAM. You could also make your own board with an SPI or QPI PSRAM chip like this .
Also maybe something like this: https://machdyne.com/product/qqspi-psram32/, https://github.com/machdyne/qqspi. (I haven't looked at these in any detail but am guessing that the ESP32S3 could support them. Not sure how they would fit into the memory map.)

I guess there are two ways to add more RAM. Looking at the ESP32S3 datasheet there is the ESP32-S3R16V version that has 16MB of in-package PSRAM. You could also make your own board with an SPI or QPI PSRAM chip like this .
Also maybe something like this: https://machdyne.com/product/qqspi-psram32/, https://github.com/machdyne/qqspi. (I haven't looked at these in any detail but am guessing that the ESP32S3 could support them. Not sure how they would fit into the memory map.)

Thanks!


Add module() and module_directory() functions

These functions should get the path to the current module's source file, and the path to the directory containing it.

Done in #2088. Added as source_file() and `source_directory(), since they work for both modules and imports.


Add appVersion for telegraf

The key "appVersion" is needed for ci testing,  but it's missing in this yaml.

/assign @seanknox

/ok-to-test
/lgtm


Support recursive listing/deletes on vsftpd

FTP Server OS: Unix
FTP Server Type: Vsftpd
Vsftpd sometimes supports recursion if enabled. We should take advantage of this as it would give a major performance boost.
From its manpage:

ls_recurse_enable - When enabled, this setting will allow the use of "ls -R". This is a minor security risk, because a ls -R at the top level of a large site may consume a lot of resources.
Default: NO

I moved this to the Future Plans list in the WIki.


How to generate a project skeleton with genie?

I was able to generate the example soultion, and I also managed to build it. However now I would like to generate a "basic" project that is linked properly to the library and the include directories also set. Tried to look it up in the lua files but not yet managed to find out how to do this with genie.
Is there a way to generate such skeleton or do I have to create it by hand?

You have to setup every project.
There is scripting reference:
https://github.com/bkaradzic/genie/blob/master/docs/scripting-reference.md#scripting-reference
Also you can look my other repositories for example how to use it.


[Question] : can SignalR-Client_Swift handle old server signalR version?

Hi,
I have a server that uses "old" signalR version (we used "https://github.com/adamhartford/SwiftR" to connect to hubs). Can I use your library to connect to this server or not? And how, I always get a connectionFails (invalid connectId) ?
Thanks ;-)

Unfortunately the new version of SignalR is not backwards compatible due to protocol changes. As a result new clients will not work with old server (or vice versa).

Thanks a lot for your answer ;-)


LXQT cursor support

Only tested on LXQt - could you check Plasma?

Works fine. However currently there is no GTK fallback. Do you think this is worth implementing?

Adwaita is default for LXQt, and Breeze is default for Plasma, so I didn't see the need really.
If however, they fall back to gtk or something like env vars instead of using those defaults we should probably do something. I'm not sure how to check that.
I think we're good though.

Just thought about falling back if the file doesn't exists, but this is very unlikely if were running the corresponding session. You're right, we are good.


client: bypass grpc dialer backoff strategy

This would bypass the grpc dialer backoff strategy and handle dial timeout
internally. Because we do not have a large number of concurrent
dialers, it is not reasonable to have such aggressive backoffs which
would kill kata containers boot up speed. For more information, see
https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md
Fixes: #320
This would speed up kata containers creation by about 0.5 second for non vm templating case and by about 1 second when vm templating is enabled.

Good catch!
lgtm


Convert entire WorkloadCVE section to use generated gql types

Description
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Current dependencies on/for this PR:

master

PR #6303

PR #6428   👈

This comment was auto-generated by Graphite.

Current dependencies on/for this PR:

master

PR #6303

PR #6428   👈

This comment was auto-generated by Graphite.

Closing this for now, this needs some rework and more thought and hasn't been a recent priority.


Add support for DHX keys to providers.

Adds a separate dhx keymanager to the providers.
DH key exchange supports the legacy kdf.
Added serialisation methods.

Checklist

[x] documentation is added or updated
[x] tests are added or updated

think you additionally need to make a change in pmeth_lib.c to the is_legacy_alg function to stop falling back to legacy code in the event of a problem.

This PR does that change. Thanks for the reminder.

dh_gettable_ctx_params was added during this PR. So the new param needed to be added once in was rebased..

@mattcaswell maybe needs reapproval for a code change.

Had to rebase again - no significant changes other than the nits related to the doc/man3/EVP_PKEY_CTX_ctrl.pod file.
(This rebase squashed the fixups).

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Thanks.. Merged to master.


Changing litmus installing steps using helm

Signed-off-by: Raj Das<EMAIL_ADDRESS>
What this PR does / why we need it:
Changing litmus installing steps using helm
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Checklist:

[ ] Fixes #
[ ] Signed the commit for DCO to be passed
[ ] Labelled this PR & related issue with documentation tag

Can we mention chaos control plane instead of chaos operator?


Add Welcome APIs

Hello i try to implement the netatmo welcome camera into Openhab2. Because the Swagger API for welcome is outdated clinique pointed me to your repository. If you need ill help in the implementation, just give me a hint or starting point what to do.

Great ! I don't have the Welcome camera so any help is much appreciated !
To start, you can open the swagger spec (https://raw.githubusercontent.com/cbornet/netatmo-swagger-decl/master/swagger.json) in swagger-editor then use the documentation from netatmo developper site to add the APIs.
To validate the spec, I generally use https://github.com/cbornet/netatmo-swagger-api java-jersey2 codegen and configure jackson with
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, true);

in JSON.java (https://github.com/cbornet/netatmo-swagger-api/blob/master/samples/netatmo/client/java-jersey2/src/main/java/io/swagger/client/JSON.java) so that it fails if I have a field missing in the response model.
Then the best is to pull a PR to the repo and I will merge.

Ok, ill have a look at the informations and try to get all up and running, in the meantime i also forked your git repository, to send a PR when im done

@cbornet Editor is ok, but i can't try the changes, i generated a key but get the errors when i want to try the apis:
´´´
This is a cross-origin call. Make sure the server at api.netatmo.net accepts GET requests from editor.swagger.io
´´´
I cloned the netatmo-swagger-api for  code validation and changed the settings in JSON.java
What i don't know is where to put my changed son file from the step before. If i just try to run  java-jersey from command line, a swagger...jar was download the first time of execution, but i get the following error:
´´´

generating java-jersey2

Exception in thread "main" io.airlift.airline.ParseArgumentsUnexpectedException: Found unexpected parameters: [--library, jersey2, --artifact-id=-java-jersey2]
at io.airlift.airline.Cli.validate(Cli.java:148)
at io.airlift.airline.Cli.parse(Cli.java:116)
at io.airlift.airline.Cli.parse(Cli.java:97)
at io.swagger.codegen.SwaggerCodegen.main(SwaggerCodegen.java:35)
´´´
Hope you could help me out, don't know how to test my changes and generate the java classes to get going with welcome implementation in OH2. Thanks

Strange : normally GET requests should work cross-domain. There is a problem with POST requests because of http://forum.netatmo.com/viewtopic.php?f=5&t=4908&p=20638&hilit=cors#p20638
As for the jersey2 generator, I'll have a look.

Hello, any news on this @cbornet ?
Ill try to get this running for the Openhab2 netatmo binding

Hello, sorry for the wait. I forgot about this issue... I'll go back on this asap.

Fixed by #11


[occm] validate flavor name, fallback on flavor id (release-1.20)

What this PR does / why we need it:
Cherry picked from #1364
Which issue this PR fixes(if applicable):
Special notes for reviewers:

Release note:

NONE

Sean Schneeweiss<EMAIL_ADDRESS>Daimler TSS GmbH, legal info/Impressum

/ok-to-test

/retest

/lgtm

/approve


⚠ Guya.moe Proxied has degraded performance

In ae9bdd9, Guya.moe Proxied (https://ice.guya.moe/) experienced degraded performance:

HTTP code: 200
Response time: 11886 ms

Resolved: Guya.moe Proxied performance has improved in 925e4af after 44 minutes.


Fixes voices directory listing

There is no name field to the voices entry, so its reference has been replaced with one to the command text.
This issue would not show itself in schemas which implement their own voices library (such as HL2RP v1.08), but rather those which use the Clockwork voices library.

Closed in favour of my rework.


Draw a rectangle around the words

Hi,
First of all thanks for this project. I was wondering if it'd be possible to improve it a little in how it generates the solution. I'd like to have the possibility to create a rectangle or other shapes around the word. Do you think you could add it?
For instance something like the following image

Thanks

It is certainly doable, and honestly, I like the look of the sample you provided. I'm not sure I will be able to get to this soon but I will certainly leave this issue open so that I can tackle it when I have some time. Thanks for the suggestion!

Hey @fabiox77, so I finally got around to implementing your suggestion. I may still adjust the colors (they are picked at random for now) so they can also work with the CLI output.
Samples below... Let me know what you think? Cheers!

sample_highlighting.pdf

Shiny! How do we access / use this?

You can install directly from git using pip...
pip install git+https://github.com/joshbduncan/word-search-generator.git


(PDB-3648) Rewrite null json chars via jackson for pg

Test PASSed

CLA signed by all contributors.

Test PASSed


Try-it: Content-type added even when no request body defined

Context
The bug affects users of Elements with endpoints without a request body. When making a request without a request body defined, elements adds a "content-type: application/json" header. This causes Prism to fail in the proxy-mode.
Current Behavior
Stoplight adds a "content-type: application/json" header on requests that don't have a request body defined.
Expected Behavior
No "content-type" header should be added if there's no request body defined. Elements should only add the "content-type" header if a request body is present.
Steps to Reproduce

Create a new OpenAPI file in Stoplight Studio with a GET endpoint without a request body.
Publish the OpenAPI file.
Go to the "Try It" section and view the request sample.
Observe that the "content-type: application/json" header is present, even though there is no request body defined.

Got this from SPS Commerce: "Our teams are well integrated with Stoplight for sending requests to our API, and so rolling out Prism in front of it has been halted for the time being until we can fix either the Prism side or the Stoplight side."

@mnaumanali94 SPS Commerce is asking for a timeline on this issue.  This is a high priority for them, it is holding up a release of theirs. Can we get this in the next sprint?

@shartman2003 We can get this in the next sprint 🙏🏼

@shartman2003 We can get this in the next sprint 🙏🏼

Much appreciated!


Update to latest upstream v0.13.8

reusing tests of a bunch of purescript libraries to test pspy's usability, special thanks to @Hong-Xiang
change license to MIT #20
update codebase to PureScript v0.13.8 #22
fix namespace issues of getitem_looper and getattr_looper


JR PACMANs arent available enough?

Description

played a couple rounds now with major power outages and people almost never seem to use jr pacmans to remedy it. maybe there needs to be some in tool storage? or they need to be easier to pull? guidebook entry already exists but maybe we need a tip as well
Reproduction

Screenshots

Additional context

i have a ton in low pop maps but i can put some more in higher pop maps

i think issue with them is you cant prioritize specific machines
a lot of powernets use more than 5kw so youd need a multitool + tray to easily find a good place to put one, at that point just go fix the actual issue with power

Letting them produce slightly more power might increase their usage as well. Basically what Delta is saying that it's really hard to power a room with just 3kw, and you have to start unwrenching everything which is cumbersome.

I feel like there are a lot already, personally.

the normal kind of pacmans arent supposed to be in maints iirc

Rip Core's maints PACMANs
But yeah we need JR PACMANs to be clustered and in familiar areas in maints and tool rooms, rather than being in the middle of nowhere and requiring good memory as opposed to intuition

I don't know which map it is, but at least one map puts them inside the substations, i.e. behind engineering access requirement. Which is completely against the point.

i dont even remember mapping pacmen :trollface: not my fault

While it's great they can power rooms with 8 kw generation, they really need to be more accessible and visible instead of memorising which dark area of maints they're in
To clarify my earlier point, they should be near maints doors, placed in tool rooms or clustered in visibly bright areas/near existing maints lockers and canisters
Another point is how common should they be? Like one room for each department or every room on the station?


Extensive Option

Hey There 😊
Can you add extensive / Expendable label option
As if in kv like number or email or address, itll be more easy to know from the different labels

Keeping this issue open. Hopefully soon!


Replace local_qasm_simulator with local_qiskit_simulator

Description

For local simulation of 10 qubits or more, the local_qiskit_simulator should be used.
Here is a comparison of running quantum_emoticon tutorial: local_qiskit_simulator takes 3.6 seconds vs local_qasm_simulator takes more than 1200 seconds.
import time
start_time = time.time()

backend = "local_qiskit_simulator"
#backend = "local_qasm_simulator"
shots_sim = 1000
results_sim = qp.execute(["smiley_writer"], backend=backend, shots = shots_sim, wait=5, timeout=300)
stats_sim = results_sim.get_counts("smiley_writer")

print("--- %s seconds ---" % (time.time() - start_time))

plot_histogram(stats_sim)

Your Environment

QISKit version: 0.4.13
Python version: 3.6
MacBookAir MacOSX with 8GM RAM and 1.6GHz i5

Don't change this. In v0.5, local_qasm_simulator will automatically select the faster simulator, if it is installed.

Noted. But for classical optimization and the above hello word program it can take more than 20 minutes to run the program. I suggest you to use local_qiskit_simulator as the generic name. In particular, because qiskit sounds familiar than qasm.
Anyway, isn't it we are using qobj instead of qasm?

closing as with qiskit 0.5 this is not longer an issue


mobs invisable bug

[04:19:59] [Server thread/INFO]: [Ridables] Loading Ridables v2.5
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: chicken
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: cow
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected new entity: dolphin_spit
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: dolphin
[04:20:00] [Server thread/INFO]: [Ridables] Dragon disabled. Skipping..
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: llama
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: mooshroom
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: ocelot
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: phantom
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: polar_bear
[04:20:00] [Server thread/INFO]: [Ridables] Could not inject new ridable entity to registry! Restart your server to try again! (sheep)
[04:20:00] [Server thread/WARN]: java.lang.ArrayIndexOutOfBoundsException: -1
[04:20:00] [Server thread/WARN]: 	at net.pl3x.bukkit.ridables.util.RegistryHax.injectReplacementEntityTypes(RegistryHax.java:70)
[04:20:00] [Server thread/WARN]: 	at net.pl3x.bukkit.ridables.Ridables.onLoad(Ridables.java:176)
[04:20:00] [Server thread/WARN]: 	at org.bukkit.craftbukkit.v1_13_R1.CraftServer.loadPlugins(CraftServer.java:319)
[04:20:00] [Server thread/WARN]: 	at net.minecraft.server.v1_13_R1.DedicatedServer.init(DedicatedServer.java:213)
[04:20:00] [Server thread/WARN]: 	at net.minecraft.server.v1_13_R1.MinecraftServer.run(MinecraftServer.java:686)
[04:20:00] [Server thread/WARN]: 	at java.lang.Thread.run(Thread.java:748)
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: turtle
[04:20:00] [Server thread/INFO]: [Ridables] Successfully injected replacement entity: wolf
any mob having the issued error: [04:20:00] [Server thread/INFO]: [Ridables] Could not inject new ridable entity to registry! Restart your server to try again! (sheep)
will not load in but sounds and action till happen

Did you read what the message said? When you see that you need to restart the server because the injection failed.
[04:20:00] [Server thread/INFO]: [Ridables] Could not inject new ridable entity to registry! Restart your server to try again! (sheep)

Try v2.6 to see if it makes those errors happen less often.

fixed the loading up but disabled mobs turn invis

some what fixed but with v2.7.3 ocelots are invis til a second restart. easy fix i think but just thought you should know and about to update to newest version


Allow pattern matching in ResultMatcher

A gotcha that has bitten my team several times is that you cannot
pattern match against the wrapped value of a result in the
ResultMatcher.
Since the basic matcher documentation shows an example where you
can pattern match against the patterns that you specify in your case
block, this is easy to assume that it's a built-in for the
ResultMatcher.
Adding pattern matching is a simple change that makes the whole of the
ResultMatcher more flexible and more in-line with the examples in the
rest of the documentation.

Thanks, it's on our list of things to do before retiring dry-transaction (see https://github.com/dry-rb/dry-transaction/issues/127). I'm merging this PR now, I'll do a few more tweaks to make pattern matching even more flexible.

Thanks for the additional context! I hadn't seen that you were planning to deprecate dry-transaction.


Update wiki for Minecraft 1.20

Please update the FabricMC wiki for Minecraft Java 1.20 as soon as possible.

I reccomend you checkout the blog post we have detailing the 1.20 changes: https://fabricmc.net/2023/05/25/120.html
The wiki is community driven, and will be updated over time, a lot of it should still apply. Feel free to reach on out discord or github discussions if you need any specific help.


server error

I have followed the instructions on the google sheets importer page, click on import.
Then a server error 500 is returned.
Can someone help us?
Regards,
Ted

hi ted, what's the sheet URL?

Hello Josh,
https://docs.google.com/spreadsheets/d/1cERocR4UEey_Hoq_pJkDI6XSLm2b-C0v6XyiSEiGWKQ/edit?usp=sharing
Regards,
Ted
On Sun, Dec 4, 2022 at 3:01 PM Josh Reisner @.***>
wrote:

hi ted, what's the sheet URL?
—
Reply to this email directly, view it on GitHub
https://github.com/code4recovery/sheets/issues/14#issuecomment-1336515984,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4SDZKRBBSMJXVHPXJ5IBZTWLUBB7ANCNFSM6AAAAAASTRSZHM
.
You are receiving this because you authored the thread.Message ID:
@.***>

Ah ok thanks. Try it again, it should work now.
It's a relatively new service, and you were the first to have blank rows in the data, which now should be no problem.
Also now it reports when it skips a row because it sees an empty ID column

Hello,
That part is working now, thanks.
In the notes there is a statement " Feeds that are not refreshed within 30
days are removed automatically"
Does this mean we need to refresh every so often?  If so how often?
I was thinking if we maintain the Google sheet schedule everything would be
updated automatically. This is new to me, I am trying to fill in, and help
out.
Regards,
Ted
On Mon, Dec 5, 2022 at 10:41 AM Josh Reisner @.***>
wrote:

Ah ok thanks. Try it again, it should work now.
It's a relatively new service, and you were the first to have blank rows
in the data, which now should be no problem.
Also now it reports when it skips a row because it sees an empty ID column
—
Reply to this email directly, view it on GitHub
https://github.com/code4recovery/sheets/issues/14#issuecomment-1337696990,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4SDZKXFX64HQ26AYQF2YMDWLYLLFANCNFSM6AAAAAASTRSZHM
.
You are receiving this because you authored the thread.Message ID:
@.***>

great, glad to hear it.
think of the sheet like a draft now. every time there's an update you'll need to visit the refresh URL to publish the changes so that users can see them
if a sheet goes more than 30 days without a refresh it's removed so that we're not showing stale data to users

Side note
The PDF generator is working for the sheet, but not for the JSON.
Regards,
Ted
On Tue, Dec 6, 2022 at 6:31 PM Josh Reisner @.***>
wrote:

great, glad to hear it.
think of the sheet like a draft now. every time there's an update you'll
need to visit the refresh URL to publish the changes so that users can see
them
if a sheet goes more than 30 days without a refresh it's removed so that
we're not showing stale data to users
—
Reply to this email directly, view it on GitHub
https://github.com/code4recovery/sheets/issues/14#issuecomment-1340205608,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4SDZKWLT45LPHDOK446D63WL7LGDANCNFSM6AAAAAASTRSZHM
.
You are receiving this because you authored the thread.Message ID:
@.***>

ah thanks. that should be fixed now


Don't hide the toolbar when pressing esc

The fullscreen code does not properly keep track of the toolbar visibility state. This leads to the following undesired behaviour:

Pressing esc without ever having entered fullscreen may hides the toolbar because toolbar_visible_ is never set.
Pressing esc after having entered fullscreen previously sets the toolbar visibility to what it was the last time fullscreen was entered.

By only calling setFullScreen(false) after we really were in fullscreen mode, we guarantee that toolbar_visible_ is valid and don't mess with the toolbar visibility otherwise.

Thanks for this contribution. To avoid breaking ABI, I removed the addition bool member variable and figure out the full-screen state on the fly.


Addition of an "About" page to the report

Currently, the report has three types of pages, namely the Home/Summary page, the variable information page(s) and the correlation page. There is a need for a fourth type called the "About page" this will be located after the correlation page in the tab list at the top of the HTML report.
The About page should include information such as the date and time the report was generated, the default parameters used for each of the functions, and any other useful information.

can i please be assigned this issue

@vrautenbach  can you please assign me this issue


Required fields seem to not work

Hey 👋
We are trying to use CUE as a schema for our configuration. What is not obvious to me is how I can make field required in terms that it needs to be provided in YAML as currently none of an examples seems to work for me :(
// dim.cue
import "encoding/yaml"

// Phrases defines a schema for a valid phrase.
Phrases :: {
    phrases: { <_>: Phrase }

    Phrase :: {
        lang:         LanguageTag
        text:         !=""
        attribution?: !="" // must be non-empty when specified

    }
    LanguageTag :: =~"^[a-zA-Z0-9-_]{2,}$"
}

// phrases is a YAML string with a field phrases that is a map of Phrase
// objects.
phrases: yaml.Validate(Phrases)

phrases: """
    phrases:
      # A quote from Mark Twain.
      quote1:
        lang: en
        attribution: Mark Twain

      # A Norwegian proverb.
      proverb:
        lang: no
        text: Stemmen som sier at du ikke klarer det, lyver.
    """

In above example if we omit text nothing happens and requirement for text being not empty is ignored, I feel that I am missing something more obvious in this scenario.
Thanks for help !

Thanks @mpvl ! Will try it later :) 🎉

This issue has been migrated to https://github.com/cue-lang/cue/issues/266.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.