text:
./gdrive: No such file or directory

I have extracted gdrive_2.1.1_linux_amd64.tar.gz on my ubuntu 20.04 but when I try to run gdrive with executable permissions I get this error.

You can use i386 binary instead amd64. It works fine for me.
wget -q -O /tmp/gdrive.tar.gz "https://github.com/prasmussen/gdrive/releases/download/2.1.1/gdrive_2.1.1_linux_386.tar.gz"
mkdir /tmp/gdrive && tar -xf /tmp/gdrive.tar.gz -C /tmp/gdrive
chmod +x /tmp/gdrive/gdrive
/tmp/gdrive/gdrive download 1o1qjRgkJtnF_8uGB1z6MRsQUjWinHUsw --recursive --path ~/Downloads

(Possible reason) The doc say this program is statically linked, which is false on amd64 build . It depends on... musl, and not glibc, which is the default on many linux distro (including ubuntu, arch, etc...). Use the i386 build which is statically linked.

I confirm that it needs musl, I had the same problem with Arch Linux

strings gdrive |egrep "[.]so$|[.]so[.]1"
yep: sudo apt install musl
strace gdrive help didnt help, but I think there is some command that let we see the dependencies other than force it thru strings

ldd  is the command you are looking for I think.

i spent near one hour to find this problem.
all those workaround always tell me to "chmod +x gdrive", which leads to nothing.
THIS confirm my sanity, that indeed it's a real bug.
@ma3yta yes, thank you i386 binary works just fine. I temporarily using this, any downside compared to amd64?

@marhensa no downsides. the program just uses 32-bit (i386) CPU instructions instead of 64-bit (amd64) instructions which is OK for x86_64 processors.

I think we should keep the issue open, until readme atleast mentions this.

I have the same issue on 2.1.1

same issue

same issue

root@localhost:~# gdrive about
-bash: /usr/local/bin/gdrive: No such file or directory
root@localhost:~# ldd gdrive
ldd: ./gdrive: No such file or directory
root@localhost:~# ldd /usr/local/bin/gdrive
	linux-vdso.so.1 (0x00007ffcaacbe000)
	libc.musl-x86_64.so.1 => not found
root@localhost:~#
root@localhost:~# apt install -y musl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  musl
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 418 kB of archives.
After this operation, 800 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 musl amd64 1.2.2-1 [418 kB]
Fetched 418 kB in 0s (2947 kB/s)
Selecting previously unselected package musl:amd64.
(Reading database ... 30457 files and directories currently installed.)
Preparing to unpack .../musl_1.2.2-1_amd64.deb ...
Unpacking musl:amd64 (1.2.2-1) ...
Setting up musl:amd64 (1.2.2-1) ...
Processing triggers for man-db (2.9.4-2) ...
root@localhost:~#
root@localhost:~#
root@localhost:~# gdrive about
Authentication needed
Go to the following url in your browser:

Confirm same issue, on a Linux 3.10 compute cluster. Musl didn't fix, using i386 seems fine.

Confirm same issue on Ubuntu x86_64 machine Linux 5.15.0-46-generic
Installing musl (via apt install musl) fixed the issue

repo: prasmussen/gdrive


text:
🛑 ChatGPT Beyond 2021 is down

In 1c0481a, ChatGPT Beyond 2021 (https://chatgpt-beyond-2021.onrender.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ChatGPT Beyond 2021 is back up in 82d4722 after 22 minutes.

source: gharchive/issue

repo: prateekralhan/status

license: MIT

license_type: permissive

license_source: github-api


text:
Campus Placements Analysis & Prediction.

Define You:

[x] Hacktoberfest2021 Participant
[x] Contributor

Is your feature request related to a problem? Please describe.
To provide script for the Campus placement analysis & prediction using a Machine Learning Algorithm in python.
Approach to be followed:
Implementing Decision Tree Regressor algorithm using a project as  Campus placement analysis & prediction which will include:

Data preprocessing & exploring,
Data visualization,
Data training &
Model creation.

@prathimacode-hub Kindly assign me for this issue.

Issue assigned. @ayushi424

repo: prathimacode-hub/PyAlgo-Tree


text:
re7 vr controls

oculus controllers with Oculus Touch Button Prompts:
how to do a 180 degree turn? this was necessary in beginning hour demo to get dirty coin
how to sort inventory in trunk? button mod prompt gives xbox view button
any others not mentioned on getting started guide png?
In order to do a 180 turn, you hit down on the left stick, and press circle if you’re on PS4, and B if you’re on Xbox One.  On PC, the keyboard button is the X button. I cannot find the control combination on the oculus controllers.
While the cursor is in the item box, you press either the view (xbox one) or the touchpad button (ps4) to auto-sort items. Not sure on PC.

https://github.com/praydog/REFramework/discussions

authors: Buzbee praydog

repo: praydog/REFramework


text:
Duplicate mosque listing on production-2.

The issue in words:
In production, mosque IDs 44488, and 66818 are for the same mosque "Miami Beach Mosque" and "Ummah Of Miami (Miami Beach Masjid)"  with the same address "7904 West Dr, North Bay Village, FL 33141. When searching for a mosque near Miami, FL, United States, two mosques with the names "Miami Beach Mosque", and "Miami Beach Mosque" is the same mosque.  the current address for "Miami Beach Mosque" is 7904 West Dr, North Bay Village, FL 33141, USA.
Steps to reproduce the issue:

Open prayersconnect.com on any browser.
Click on the search bar to find mosques near you.
Type in "Miami, FL, United States" and search.
Will be able to find two mosque listing with the names "Miami Beach Mosque", and "Ummah Of Miami (Miami Beach Masjid)"
There should be just one mosque "Miami Beach Mosque" with the address of "7904 West Dr, North Bay Village, FL 33141, USA"

Done

repo: prayersconnect/qa


text:
Jordan's new test issue or old GPS issue

test text

#290

repo: precision-sustainable-ag/Hotline-Issues


text:
pixi add arize-phoenix fails due to dependency conflict, where as plain pip install arize-phoenix works.

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
Here is my pixi.toml file:
[project]
name = "bla_bla"
version = "0.1.0"
description = "Add a short description here"
authors = ["Damian Barabonkov <damianb@alum.mit.edu>"]
channels = ["conda-forge"]
platforms = ["osx-arm64"]

[tasks]

[dependencies]
black = "*"
jupyterlab = "*"
notebook = "*"
pandas = "*"
pre-commit = "*"
pyarrow = "*"
python = "3.11.*"
pyright = "*"
pip = ">=24.0,<25"

[pypi-dependencies]
openai = "*"
dspy-ai = ">=2.4.9"
arize-phoenix = "*"

Version: pixi 0.21.0
Issue description
I first thought that this was an issue with the library arize-phoenix, however after seeing that pip install works, that leads me to think that this is a pixi issue.
I have a pixi environment set up as above. Doing pixi add arize-phoenix or pixi add --pypi arize-phoenix leads to a dependency conflict. However, if I do pixi add pip and then pip install arize-phoenix, it works out just fine.
Here is the arize-phoenix repo: https://github.com/Arize-ai/phoenix
Expected behavior
The installation works like pip install does.

Hey @DamianB-BitFlipper, what error do you receive, and could you run with a -vv flag to make the output verbose?

Sure! Here's the output:
 × failed to solve the pypi requirements of 'default' 'osx-arm64'
  ├─▶ Failed to build: `scikit-learn==1.4.2`
  ├─▶ Failed to install requirements from build-system.requires (install)
  ├─▶ Failed to download and build distributions
  ├─▶ Failed to fetch wheel: scipy==1.13.0
  ├─▶ Failed to build: `scipy==1.13.0`
  ╰─▶ Build backend failed to build wheel through `build_wheel()` with exit status: 1
      --- stdout:
      + meson setup /Users/damianb/Library/Caches/rattler/cache/uv-cache/built-wheels-v3/pypi/scipy/1.13.0/63ZSyGLCiC4j7AqyrZiy7/scipy-1.13.0.tar.gz /Users/damianb/Library/Caches/rattler/cache/uv-cache/built-
      wheels-v3/pypi/scipy/1.13.0/63ZSyGLCiC4j7AqyrZiy7/scipy-1.13.0.tar.gz/.mesonpy-z78og_vx -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/Users/damianb/Library/Caches/rattler/cache/
      uv-cache/built-wheels-v3/pypi/scipy/1.13.0/63ZSyGLCiC4j7AqyrZiy7/scipy-1.13.0.tar.gz/.mesonpy-z78og_vx/meson-python-native-file.ini
      The Meson build system
      Version: 1.4.0
      Source dir: /Users/damianb/Library/Caches/rattler/cache/uv-cache/built-wheels-v3/pypi/scipy/1.13.0/63ZSyGLCiC4j7AqyrZiy7/scipy-1.13.0.tar.gz
      Build dir: /Users/damianb/Library/Caches/rattler/cache/uv-cache/built-wheels-v3/pypi/scipy/1.13.0/63ZSyGLCiC4j7AqyrZiy7/scipy-1.13.0.tar.gz/.mesonpy-z78og_vx
      Build type: native build
      Project name: scipy
      Project version: 1.13.0
      C compiler for the host machine: cc (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
      C linker for the host machine: cc ld64 1053.12
      C++ compiler for the host machine: c++ (clang 15.0.0 "Apple clang version 15.0.0 (clang-1500.3.9.4)")
      C++ linker for the host machine: c++ ld64 1053.12
      Cython compiler for the host machine: cython (cython 3.0.10)
      Host machine cpu family: aarch64
      Host machine cpu: aarch64
      Program python found: YES (/Users/damianb/Library/Caches/rattler/cache/uv-cache/.tmp85jgea/.venv/bin/python)
      Found pkg-config: YES (/opt/homebrew/bin/pkg-config) 0.29.2
      Run-time dependency python found: YES 3.11
      Program cython found: YES (/Users/damianb/Library/Caches/rattler/cache/uv-cache/.tmp85jgea/.venv/bin/cython)
      Compiler for C supports arguments -Wno-unused-but-set-variable: YES
      Compiler for C supports arguments -Wno-unused-function: YES
      Compiler for C supports arguments -Wno-conversion: YES
      Compiler for C supports arguments -Wno-misleading-indentation: YES
      Library m found: YES

      ../meson.build:78:0: ERROR: Unknown compiler(s): [['gfortran'], ['flang'], ['nvfortran'], ['pgfortran'], ['ifort'], ['ifx'], ['g95']]
      The following exception(s) were encountered:
      Running `gfortran --version` gave "[Errno 2] No such file or directory: 'gfortran'"
      Running `gfortran -V` gave "[Errno 2] No such file or directory: 'gfortran'"
      Running `flang --version` gave "[Errno 2] No such file or directory: 'flang'"
      Running `flang -V` gave "[Errno 2] No such file or directory: 'flang'"
      Running `nvfortran --version` gave "[Errno 2] No such file or directory: 'nvfortran'"
      Running `nvfortran -V` gave "[Errno 2] No such file or directory: 'nvfortran'"
      Running `pgfortran --version` gave "[Errno 2] No such file or directory: 'pgfortran'"
      Running `pgfortran -V` gave "[Errno 2] No such file or directory: 'pgfortran'"
      Running `ifort --version` gave "[Errno 2] No such file or directory: 'ifort'"
      Running `ifort -V` gave "[Errno 2] No such file or directory: 'ifort'"
      Running `ifx --version` gave "[Errno 2] No such file or directory: 'ifx'"
      Running `ifx -V` gave "[Errno 2] No such file or directory: 'ifx'"
      Running `g95 --version` gave "[Errno 2] No such file or directory: 'g95'"
      Running `g95 -V` gave "[Errno 2] No such file or directory: 'g95'"

      A full log can be found at /Users/damianb/Library/Caches/rattler/cache/uv-cache/built-wheels-v3/pypi/scipy/1.13.0/63ZSyGLCiC4j7AqyrZiy7/scipy-1.13.0.tar.gz/.mesonpy-z78og_vx/meson-logs/meson-log.txt
      --- stderr:

      ---

I think it might be related to system-requirements. Can you add macos = 13 to the system requirements table?
https://pixi.sh/latest/reference/configuration/#the-system-requirements-table

Can you try 13.0. Sorry.

It works! Why did this fix it? Also, why the 13.0? Thanks in any case!

14.0 would also work. The thing is that often times wheel files are not build for older osx versions anymore. Wheels make it much easier to install PyPI dependencies.

Could you please elaborate why you think it was failing in this case? This is a real learning moment for me with regards to Python packaging. Thanks!

If you look at the arm64 whl files listed here: https://pypi.org/project/scipy/#files you can see that they are all for macos_12.0. That means that they do require a higher "baseline". If we cannot find a wheel, we try to build the package from scratch (from the sdist).
That is why you are seeing the gfortran and other compilation issues from the attempt at compiling scipy.
If you want to speed up even more then you could also try to use the following two constraints in the conda dependencies (installing hdbscan was a bit slow for me):
hdbscan = ">=0.8.33"
joblib = "<1.4.0"

We (as in pixi) need to improve the systme requirements stuff. Probably by using a higher default.

Thanks for the clarification.

authors: DamianB-BitFlipper ruben-arts wolfv

repo: prefix-dev/pixi


text:
pixi run selection should only open up if task is not in default feature

[project]
name = "polarify"
description = "Simplifying conditional Polars Expressions with Python 🐍 🐻❄"
channels = ["conda-forge"]
platforms = ["linux-64", "osx-arm64", "osx-64", "win-64"]

[dependencies]
python = ">=3.9"
polars = ">=0.14.24,<0.21"

[tasks]
postinstall = "pip install --no-build-isolation --no-deps --disable-pip-version-check -e ."

[feature.py39.dependencies]
python = "3.9.*"
[feature.py310.dependencies]
python = "3.10.*"
[feature.py311.dependencies]
python = "3.11.*"
[feature.py312.dependencies]
python = "3.12.*"

[host-dependencies]
python = "*"
pip = "*"
hatchling = "*"

[feature.test.dependencies]
pytest = "*"
pytest-md = "*"
pytest-emoji = "*"
hypothesis = "*"
[feature.test.tasks]
test = "pytest"

[feature.lint.dependencies]
pre-commit = "*"
[feature.lint.tasks]
lint = "pre-commit run --all"

[environments]
default = ["py312", "test"]
py39 = ["py39", "test"]
py310 = ["py310", "test"]
py311 = ["py311", "test"]
py312 = ["py312", "test"]

$ pixi run postinstall
✨ Pixi task (default): pip install --no-build-isolation --no-deps --disable-pip-version-check -e .
...
$ pixi run test
? The task 'test' can be run in multiple environments.

Please select an environment to run the task in: ›
❯ default
  py39
  py310
  py311
  py312

I'm actually not sure if that is a better user experience, as there is no auto completion on the cli -e command.

The availability of the test command is basically the same as the postinstall command. I find it a bit irritating that they behave differently 😅
Maybe we should add all commands available to the default env to autocompletion?

Fixed by #772

authors: pavelzw ruben-arts


text:
Add ability to not include host and/or build dependencies

Problem description
It would be nice to be able to not include host dependencies and build dependencies into the environment.
Maybe something like pixi install --no-include-host-dependencies
This would enable a use case where you want to have a prod environment without host dependencies
[dependencies]
python = ">=3.12"
pip = "*"

[tasks]
start = "uvicorn"

[host-dependencies]
hatchling = "*"

[feature.test.dependencies]
pytest = "*"

[feature.wheel.dependencies]
build = "*"
[feature.wheel.tasks]
build-wheel = "python -m build --no-isolation" # use hatchling from pixi env

[environments]
default = ["test"]
prod = []

in production docker container:
$ pixi run build-wheel
$ pixi install -e prod --no-include-host-dependencies
# not sure if we should still install this into the same location as if we would do with `pixi install -e prod`?
$ pixi run -e prod pip install dist/my-package.whl
$ pixi run -e prod start

Maybe we could also leverage rip to remove pip from the runtime dependencies and be able to install the wheel on top?

I might just be missing something, but couldn't this already be handled by multi-envs? Eg,
[dependencies]
python = ">=3.12"
pip = "*"

[tasks]
start = "uvicorn"

[feature.test.dependencies]
pytest = "*"

[feature.build.dependencies]
build = "*"
hatchling = "*"

[feature.build.tasks]
build-wheel = "python -m build --no-isolation" # use hatchling from pixi env

[environments]
default = ["test", "build"]
prod = []

Yes, you're right. But for my use-case, I want to keep the semantic information what is a host-dependency s.t. other tools can also use this information. (I'm planning a tool that keeps your recipe.yaml for rattler-build in sync with the pixi.toml). Also I would like to actually use the host-dependencies with what they were intended for 😅

Ah, fair enough! 🙂

Closing this in favor of the pixi build work which will most-likely reignite the use of the tables.

authors: msegado pavelzw ruben-arts


text:
feat: add environ support

Honestly, I haven't found a bug with the code yet, tried a few recipes with environ, but I definitely feel like I might be missing something, are there specs or docs about environ and it's behaviour?
Fixes #138

I think the most important thing is that we record the environment variables used to build so we can reproduce them. It would also be good to have a distinction between secrets and normal environment variables. Secrets should not be stored and/or outputted.
Also, can we please rename environ to either environment or env?

Yeah, I agree with Bas here. Although this "environ" is different from the script_env in that we just use it to template some values into the YAML.
Tracking them in the used variables might be good though.

Hmm. I think we should consider somehow avoiding storing the entire ENV seems like a security risk(considering people might use it with production .env).
Let me think what we can do, though not including secrets might also hurt reproducibility...

Hmm, I am also considering to just keep it as is for now. We'll have the rendered recipe (from #246) that contains the values of the environment variables and which we would use to rebuild the package.
It might be nice to warn if a environment variable is not set, but even that can be deliberate, so might be tricky. Maybe this is the way to go.

Some discussion:
To better capture the user intent, we could make env a minijinja object with two functions:

env.get("BLA") errors when the env variable isn't found
env.get_default("BLA", "BLUBB"), uses the BLUBB default when BLA is not set

Looks good to me.

Do you want to add a couple of unit tests?

source: gharchive/pull-request

authors: baszalmstra swarnimarun wolfv

repo: prefix-dev/rattler-build


text:
add support for custom service

fixes #244

Please update the readme env var section https://github.com/premAI-io/prem-app#environment-variables

authors: Janaka-Steph jigneshsolanki

repo: premAI-io/prem-app


text:
🛑 Beta is down

In fa3ee3f, Beta (https://beta.presquelabs.com) was down:

HTTP code: 400
Response time: 651 ms

Resolved: Beta is back up in dbe4c9c.

repo: presquelabs/upptime


text:
Enable jwt middleware customization

When we want to create a custom jwt middleware, this is already possible, but the prest besides registering the customized middleware also registers the standard middleware, which often ends up taking out effect of the customized middleware

I'm very interested in this issue.
IMO the simplest solution is to add a config to disable prest jwt middleware.
So here instead of  using
if !config.PrestConf.Debug {
 	MiddlewareStack = append(MiddlewareStack, JwtMiddleware(config.PrestConf.JWTKey))
 }

Use something like
if !config.PrestConf.DisableJWTMiddleware {
 	MiddlewareStack = append(MiddlewareStack, JwtMiddleware(config.PrestConf.JWTKey))
 }

What do you guys think?
May I propose a PR for that?

i guess we can i little bit different
if !config.PrestConf.Debug  && config.PrestConf.EnableJWTDefault /*default true */ {
 	MiddlewareStack = append(MiddlewareStack, JwtMiddleware(config.PrestConf.JWTKey))
 }

@franciscocpg feel free to send a PR

@felipeweb
If we have a separate config for enable/disable the default jwt, do we still need to check debug config?
I mean if config.PrestConf.EnableJWTDefault wouldn't be enough?

Yes
On Wed, 18 Oct 2017 at 13:46 Francisco Guimarães notifications@github.com
wrote:

@felipeweb https://github.com/felipeweb
If we have a separate config for enable/disable the default jwt, do we
still need to check debug config?
I mean if config.PrestConf.EnableJWTDefault wouldn't be enough?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prest/prest/issues/230#issuecomment-337636045, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEpfGVpO3Rup8XQd6lcKxTOUUIuMiBCIks5sth1ggaJpZM4Px8tZ
.

@franciscocpg to maintain the default behavior we need both, the debug mode off enable jwt and  if we want customize jwt we need to disable default jwt so other env var

authors: EltonSouza felipeweb franciscocpg

repo: prest/prest


text:
Fix predicate push-down accuracy

I think this is a coding error which will not affect the final result.
I think it's unreasonable for lower bound to have a BELOW bound type.
When the query condition is < 3, then it will change to <= 3 according to this code:
KuduPredicate.ComparisonOp op = (high.getBound() == BELOW) ? LESS : LESS_EQUAL;
With this error code, the predicate push-down will get more data returned.

@Praveen2112 Would you like to take a look?

authors: Crossoverrr kokosing

repo: prestosql/presto


text:
Add secrets documentation

Contributed from https://docs.starburstdata.com/latest/security/secrets.html

Thanks!

authors: electrum mosabua


text:
Timer: executes an AJAX request, even if the "listener" attribute is absent

Describe the bug
I only use pe:timer to execute javascript:
<pe:timer
    widgetVar="myTimer"
    global="false"
    visible="false"
    timeout="100"
    ontimercomplete="myJavaScriptFunction();"
    singleRun="true" />

So, the listener attribute is missing and everything works fine..., but the ajax-request is still triggered as a result of the timer complete.
IMHO it's not right.
Furthermore, I can see in the source code (timer.js) that this shouldn't really be the case:
stop: function (silent, end) {
        if (!silent && this.cfg.listener) {
            this.cfg.listener();
        }

but it doesn't seem to be working the way it should.
FYI: workaround, which I found, for my use-case is:
$(document).ready(
    function() {
        PF('myTimer').stop = function(silent, end) {
            PrimeFaces.widget.ExtTimer.prototype.stop.call(this, true, end);
        }
    }
);

Reproducer
If there is no listener attribute, no ajax requests should occur
Expected behavior
If there is no listener attribute, no ajax requests should occur
PrimeFaces Extensions version
13.0.2
JSF implementation
Mojarra
JSF version
2.3
Browser(s)
Chrome/118.0.0.0

You can probably also use <pe:timer onstart="return false"/> as a workaround, it's what I use in general when I don't need AJAX requests to be sent. The this.cfg.listener is not what you define on the component, it appears to be always set

I will take a look at this.

@Gmugra this component has been around a long time (since way before I joined this project) and I don't think it is quite right as you mentioned and @blutorange mentioned its ALWAYS setting the listener for some reason?

Even weird I have no idea why it has a Handler: https://github.com/primefaces-extensions/primefaces-extensions/blob/master/core/src/main/java/org/primefaces/extensions/component/timer/TimerHandler.java

You can probably also use <pe:timer onstart="return false"/> as a workaround, it's what I use in general when I don't need AJAX requests to be sent. The this.cfg.listener is not what you define on the component, it appears to be always set

Thanks for the tip, this way is better :)

@melloware,
I also don't understand what for it has a Handler, and why listener is always set :)
(Furthermore, if it is always set, why check for it in javascript? )
But I'm not a big enough JSF expert to be 100% sure. Sorry.
I'd say it's just some legacy with some old bugs :)
Yes, the component exists since version 3, i.e. ~10 years.
It would be useful to check the history of old changes, maybe that would clarify things;
but as far as I can see, here exists a history of changes from 2020, not 2014. :(

authors: Gmugra blutorange melloware


text:
Release/2.17.2

This release contains one change:

Fixes issue where Cardholder Name input field in headless would not accept spaces

Release checklist:

[x] Bump the version in .podspec file
[x] Commit and push change to release/2.17.2
[x] Add tag 2.17.2
[ ] Release via Spinnaker
[ ] Validate release on Cocoapods

repo: primer-io/primer-sdk-ios


text:
ActionMenu does not have hover styles in Dark high contrast theme

Description
https://user-images.githubusercontent.com/1863771/197777432-8afc5d79-a5ad-43b8-a3ec-00f92897e5b3.mov
Steps to reproduce

Go to https://primer.style/react/ActionMenu
Change theme to Dark high contrast
Hover on menu items

Version
v35.12.0
Browser
Chrome

@siddharthkp let's prioritize a fix for a11y sake

Hi @factscub, this one is already assigned to a Primer React maintainer but if you'd like to give it a go, feel free to submit a PR for consideration.

Hey @joshblack, @tallys, @siddharthkp,
I started looking into this issue as it was open for some time now. Below are the following details.
Currently the background of the ActionMenu is set to ${get('colors.canvas.overlay')} which is equivalent to overlay: get('scale.gray.8'). Here the overlay value is set to scale.gray.8 now if we see the hover background of ActionListItem which is all the elements in the ActionMenu we can see it has a background of scale.gray.8 as well.  So since both has the same background the ActionMenu doesn't have hover styles. So to fix this we can do few things.

We can change the hoverBg of ActionListItem over here from scale.gray.8 to scale.gray.6. But doing this it can change the default hover style behaviour of the ActionListItem and also this change isn't required where the component containing ActionListItem doesn't have a background of scale.gray.8.

We can add a new variant over here along with default and danger which can be named as actionMenu and then we can add something like .

actionMenu: {
   // this can be change to any other value but keeping it different here from bg which is scale.gray.8
   // so that hover works
    hoverBg: get('scale.gray.4'),
    activeBg: get('scale.gray.6'),
}

Since activeBg is also dependent on variant here we need to add that as well. All the available dark_high_contrast scale gray colors can be found here.
And then we can add this new variant in ActionMenu.stories, ActionMenu.examples, ActionMenuStories.featues and this way we can fixed the hover of ActionMenu component without affecting any other component which uses ActionListItem.
Please let me know what you guys think about this or if you guys have any better suggestions to handle this will be really great.
Thanks!

Hi @electron97 👋🏻
Thanks so much for taking a look at this issue and digging deep into it! We appreciate your work 🙏🏻
I humbly have a couple of thoughts regarding the solutions and we can chat further about it them find the best way.

We can change the hoverBg of ActionListItem over here from scale.gray.8 to scale.gray.6. But doing this it can change the default hover style behaviour of the ActionListItem and also this change isn't required where the component containing ActionListItem doesn't have a background of scale.gray.8.

I agree with you. ActionListItem is used in multiple places without the ActionMenu context and changing it to scale.gray.6 would change all the other hover backgrounds too. This wouldn't be an isolated change and refraining from this sounds like a good idea 👍🏻

We can add a new variant over here along with default and danger which can be named as actionMenu and then we can add something like .

I would be hesitant about introducing a new variant and updating the variant of ActionList.Item components that are used in ActionMenu context to the new variant mainly because this would be a breaking chance. And this would require an update in all downstream repos.
One isolated solution I thought is that maybe we can look into conditionally setting the hover background color depending on where the ActionList.Item is used and we might determine this in the code like we did for roles.  It is inspired by your second solution, it just adds a pivot into it to gather the context in the code rather than explicitly setting with a variant.
Let me know what you think and if you have any questions or anything I misunderstood! Thanks so much again!

Hi, After some more digging into the issue, I asked @langermank for some advise on whether we should update a primitive for it. She pointed me to view_component's implementation which includes a hover border which shows up in case of this particular theme.
Here's the link.
With this as a reference, I have a PR correcting this for primer-react. However storybook examples for ActionMenu in primitives also suffer from the same issue. Do we need to fix it as part of this issue? Maybe not?

authors: broccolinisoup electron97 lesliecdubs pksjce siddharthkp tallys

repo: primer/react


text:
Error occured after command: "docker-compose up"

The error messages are listed below:
ERROR: Version in "./docker-compose.yml" is unsupported. You might be seeing this error because you're using the wrong Compose file version. Either specify a supported version (e.g "2.2" or "3.3") and place your service definitions under the services key, or omit the version key and place your service definitions at the root of the file to use version 1.
For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/

Yes, it's a issue, thx.

In fact the latest docker also supports 3.9.  See: here https://github.com/docker/cli/pull/2073/commits/5bc1f24dfd9f0071f7b857658c38226b695a0997.
Anyway I will follow docker compose docs.

Thanks for ur replay! In fact, this is my very first time using docker, hopefully it's not my problem. Wish it will work well soon. Many thanks!

Fix in this pull request
I'll close this issue.

repo: primihub/primihub


text:
CTC Prediction using Regression Models

CTC Prediction of freshers with the data available as College data , city data etc .
Different Regression Models are used and the accuracy levels are tested and scrutinized .

Revert for any concern


text:
Using crows pairs multiple times will result in different measurements

hi,
I ran into a problem with multiple crows-pairs metrics with different results. After training the model using bert-base-cased/ save locally, I used crows pairs multiple times to measure different results. Figure:

Thank you very much for answering my questions and solving them, which is very helpful for my research.

Hi,
I'm not sure I fully understand your question—are you saying that you are getting high variance in CrowS-Pairs results from using bert-base-cased instead of bert-base-uncased? I've only ever tried training with uncased models, as I don't think casing particularly matters for any of the tasks at hand (either upstream or downstream).
From your attached screenshot, the numbers look reasonable (a deviation of 3.82 from 50—the ideal score), but for a sanity check you could compare them against bert-base-cased without any further training. Even in the cased setting, I would expect MABEL to have a better CrowS-Pairs score than BERT.
CrowS-Pairs is also a relatively small dataset (only 266 examples), so I would expect some variance across training runs. But if you are loading an already trained checkpoint and just running the metric multiple times, then the numbers should not change.

My problem was loading a trained checkpoint and ust running the metric multiple times,with different results each time.I don't know what the reason is, but the same thing happens with other metrics.
All training steps are not different from the commands provided.

hi,
My problem was loading a trained checkpoint and ust running the metric multiple times,with different results each time.I don't know what the reason is, but the same thing happens with other metrics.
All training steps are not different from the commands provided.

I'm not sure why you're running into this issue--I just tried re-running CrowS-Pairs locally with a saved checkpoint, and the results were fixed. To debug, I'd recommend the following:

Try cloning a fresh copy of the repository and running python -m benchmark.intrinsic.crows.eval --model_name_or_path princeton-nlp/mabel-bert-base-uncased. The numbers should exactly match what was reported in README.md, since we are downloading and loading from a frozen checkpoint.
If the numbers do match exactly, try replacing princeton-nlp/mabel-bert-base-uncased with the local path to your trained model (and also make sure that you are using a compatible tokenizer).

Do you also get varying results from the same trained checkpoint on StereoSet?

I use your trained princeton-nlp/ mable-bert-base-uncased without this issue. This is a problem when I retrain using your code. Using stereosets has the same problem.
Is it because the argument wasn't saved where I highlighted it in red?

I'm not sure which part of the training was wrong.

Did you convert the trained model checkpoint to its HF checkpoint prior to intrinsic evaluation? From the README:

If you use your own trained model instead of our provided HF checkpoint, you must first run python -m training.convert_to_hf --path /path/to/your/checkpoint --base_model bert (which converts the checkpoint to a standard BertForMaskedLM model - use --base_model roberta for RobertaForMaskedLM) prior to intrinsic evaluation

I tried a training run locally, and converted the checkpoint before running CrowS-Pairs. I did not get the message boxed in red.

After I ran python -m training.convert_to_hf --path /path/to/your/checkpoint --base_model bert, the problem was solved.
Thank you very much for your patience to help me solve this problem.

That's great! Glad it worked out.
I'm closing this issue for now, but feel free to re-open or start a new thread if you run into additional issues.

repo: princeton-nlp/MABEL


text:
Bugfix v1.3.4

@David-Yan1  Fixed bug where individual export would fail on objects hidden from viewport
@mazeyu Fixed Terrain.populated_bounds bad merge

Fixes #247

repo: princeton-vl/infinigen


text:
Suggestions only given for first word in line

If I have two words underlined as mispelled and want to leave the first as is (without adding to the dictionary) the suggestions remain for the even if the cursor is in the second.

Can anyone confirm?

Yes, this is how it currently works. I think that when the cursor is on a flagged word the status line should show the suggestions for this word. I just proposed that navigating to a flagged word be implemented #8. That should contribute to fixing this issue.

authors: mardukbp reagle

repo: priner/micro-aspell-plugin


text:
Incorrect example queries in the next steps page of the MongoDB Getting Started guide

Context
The Next Steps page in the MongoDB getting started guide has a number of example queries under the subsection Expand for more Prisma Client API examples.  However, most of these queries do not match the schema provided in the Creating the Prisma schema page of the same guide.  This is true for both the javascript and typescript tutorials.
This might be confusing for new users.
Details
const filteredPosts = await prisma.post.findMany({
  where: {
    OR: [{ title: { contains: 'hello' } }, { content: { contains: 'hello' } }],
  },
})

Tries to use the  content field, which does not exist in post. Should be body.

const post = await prisma.post.create({
  data: {
    title: 'Join us for Prisma Day 2020',
    author: {
      connect: { email: 'alice@prisma.io' },
    },
  },
})

Tries to connect to the author relation field which does not exist in post. Should be user.
Missing mandatory fields slug and body

const posts = await prisma.profile
  .findUnique({
    where: { id: 1 },
  })
  .user()
  .posts()

No model called profile in the schema.

I would be happy to make a PR to fix this.

PR would be great indeed @TasinIshmam

Great, I'll update with a fix :smile:  @janpio

authors: TasinIshmam janpio

repo: prisma/docs


text:
We should highlight that using prisma.raw() with parameters is not secure and recommend using prisma.raw``

Problem
Users are using prisma.raw() like
const data = await prisma.raw(
  `SELECT * FROM "ProviderItemAttribute" WHERE "provider_item" = ${root.id} AND "user" = ${auth.user.id} limit 1;`,
);

This example is using prisma.raw() the pure text version so there is no security around parameters.
Only raw`` is secure because it's using https://github.com/blakeembrey/sql-template-tag
Solution
In this case it would be recommended to do
const data = await prisma.raw`
	SELECT * FROM "ProviderItemAttribute" WHERE "provider_item" = ${root.id} AND "user" = ${auth.user.id} limit 1;
`;

This should be highlighted in the docs (and examples?)
We also can think about how to warn users that are using prisma.raw() or even disable it under a flag?
Note prisma.raw`` parameters do not work as of today with PostgreSQL see https://github.com/prisma/prisma-client-js/issues/595

I still have concerns that it's way too easy to accidentally use parentheses when you actually don't want to. Would it be possible to maybe introduce a second method which just allows template literal inputs (e.g. raw`SELECT 1` ) which disallows using parentheses (e.g. raw(`SELECT 1`), and a new method which just allows passing in data unescaped via a string rawWithoutEscape (similar to react's dangerouslySetInnerHtml.

IMO, this is not just a docs issue – highlighting it in the docs is NOT enough. In fact, the current docs are long outdated, which shows how many users actually read them before using a feature. It's not enough.

I just realised that when you let autocompletion do its job, it will default to the parentheses method, which means no escaping will be done. That's very dangerous

Then please open an issue in the appropriate place instead of talking to yourself in the docs repo @Luca :D

Could we just transfer it back to prisma/prisma? You moved it here in the first place.

I moved it here as it was tagged as devrel  + docs (I assume, that is why things are moved here), and thus belongs here.

Include: https://prisma-company.slack.com/archives/C4GCG53BP/p1593513246334300

Docs are ✨
https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/raw-database-access

authors: Jolg42 janpio mhwelander steebchen


text:
:cyclone: Move database deconnection to the finally block

Describe this PR
The purpose of this PR is to refactor the legacy code which disconnects the database twice :
1 . In the Success phase of the promise.
2. In the Failed phase of the promise.
It is possible to set await prisma.$disconnect() in the finally block of the code you provided. This ensures that the connection to the database is always properly closed, regardless of whether the then or catch block is executed.
Changes
I have added a new block finally and moved prisma.$disconnect() inside it.
Before
main()
  .then(async () => {
    await prisma.$disconnect()
  })
  .catch(async (e) => {
    console.error(e)
    await prisma.$disconnect()
    process.exit(1)
  })

After

main()
	.then(async () => {
		console.log('Success');
	})
	.catch(async (e) => {
		console.error(e);
		process.exit(1);
	})
	.finally(async () => await prisma.$disconnect());

Unfortunately after our docs migration is this a change that should now be in a number of new pages. If you'd like to re-submit, please let us know and we'd be happy to help!

authors: alamenai jharrell


text:
Fix/light theme display

Fixes #900 (not implementing an option to clear what accumulates in the subscription).
Changes proposed in this pull request:

enable display time showed in light theme.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the PR! It will be in next release! 🚀

authors: CLAassistant Huvik yoshiakis

repo: prisma/graphql-playground


text:
Chaining relations

Problem
JS Client supports chained relations, but the Go client does not
const postsByUser: Post[] = await prisma.user
  .findOne({ where: { email: 'alice@prisma.io' } })
  .posts()

Suggested Solution
posts, err := client.User.FindOne(...).Posts(...).Exec(ctx)

duplicate of https://github.com/prisma/prisma-client-go/issues/104 and was abandoned due to https://github.com/prisma/prisma-client-go/issues/104#issuecomment-624567858

authors: matthewmueller steebchen

repo: prisma/prisma-client-go


text:
Order by Relations not work

Bug description
Order by Relations not work in version 2.21.2
How to reproduce
My code:
prisma.product.findMany({
    orderBy: {
         analytics: {
             id: 'acs'
         }
      }
})

Type '{ analytics: {}; }' is not assignable to type 'Enumerable<ProductOrderByInput>'.
  Object literal may only specify known properties, and 'analytics' does not exist in type 'Enumerable<ProductOrderByInput>'

Expected behavior
No response
Prisma information
model Product {
  id               Int            @id @default(autoincrement())
  analytics       Analytic[]    @relation("fk_product_analytic")
  @@map("products")
}

model Analytic {
  id                        Int                   @id @default(autoincrement())
  product_id                Int
  product                   Product               @relation("fk_product_analytic", fields: [product_id], references: [id])

  @@map(name:"product_analytics")
}

Environment & setup

Node: 14.16.0

Prisma Version
2.21.2

Does this work in a more recent version of Prisma?

Hi @NguyenKyThinh94,
Not sure if you’ve already managed to get around your issue (or if this will be helpful to anyone else reading this) but I was also seeing this error in v2.30.3.
In my situation, when I actually ran my app the order by relation was working but I was seeing the above type error. To get rid of the error I just cast my object to the expected type and it seemed to be happy enough with it.
So in your example, something along the lines of:
const orderBy = { analytics: { id: ‘acs’ } } as ProductOrderByInput
prisma.product.findMany({ orderBy })

Thanks

instead of using orm, i wrote SQL query !!
Many thanks for supports

I'm able to order by relations in v3.14
Not sure if trying to order by 'acs' instead of the correct 'asc' has anything to do with the issue.
    const cyProjects = await db.projects.findMany({
        select: {
          ProjectNumber: true,
          ProjectName: true,
          Clients: {
            select: {
              ClientName: true,
              ClientId: true,
            },
          },
        },
        where: {
          ProjectNumber: { startsWith: '22' },
        },
        orderBy: {
          Clients: { ClientId: 'asc' },
        },
      })

Please try this again with the latest version of Prisma. This preview feature has been stabilized since the version that you using. @NguyenKyThinh94

There are a few things in this issue...
First, please upgrade to the latest Prisma version (4.3.1 currently) to use the feature.
Second, the only ordering you can do from a many side of the relation is by _count, so this would work:
await prisma.product.findMany({
  orderBy: {
    analytics: {
      _count: "asc",
    },
  },
});

Which translates to the following SQL:
SELECT "public"."products"."id"
FROM "public"."products"
         LEFT JOIN (SELECT "public"."product_analytics"."product_id", COUNT(*) AS "orderby_aggregator"
                    FROM "public"."product_analytics"
                    WHERE 1 = 1
                    GROUP BY "public"."product_analytics"."product_id") AS "orderby_0_Analytic"
                   ON ("public"."products"."id" = "orderby_0_Analytic"."product_id")
WHERE 1 = 1
ORDER BY COALESCE("orderby_0_Analytic"."orderby_aggregator", $1) ASC
OFFSET $2

But you can't really order by a specific column from the many side, that only works from the one side:
await prisma.analytic.findMany({
  orderBy: {
    product: {
      id: "asc",
    },
  },
});

And this translates to the following SQL:
SELECT "public"."product_analytics"."id", "public"."product_analytics"."product_id"
FROM "public"."product_analytics"
         LEFT JOIN "public"."products" AS "orderby_0_Product"
                   ON ("public"."product_analytics"."product_id" = "orderby_0_Product"."id")
WHERE 1 = 1
ORDER BY "orderby_0_Product"."id" ASC
OFFSET $1

So, from the many side, the parent can have more than one children. There would not really be a good way to order the parents by the ids of more than one children. From the one side, there can be at most one parent. Now we have a way to order by a column of this parent.

Hello @pimeys ,
So, how do you make this select work below in Prisma?
SELECT ch.* FROM challenges ch
JOIN user_challenges uc
ON uc.challenge_id = ch.id
WHERE uc.user_id = '************'
AND uc.completed = true
AND uc.is_current = true
ORDER BY uc.end_date DESC

My model looks like this (reduced).
model Challenge {
...
user_challenges                     UserChallenges[]
...
}
model UserChallenges {
...
user_id                 String                                  @db.Uuid
completed           Boolean                               @default(false)
is_current            Boolean                               @default(true)
end_date             DateTime?                           @db.Timestamptz(6)
challenge            Challenge                            @relation(fields: [challenge_id], references: [id])
...
}

And this here doesn't really work.
const challengesFound = await prisma.challenge.findMany({
  where: {
    user_challenges: {
      some: {
        user_id,
        completed: true,
        is_current: true,
      },
    },
  },
  orderBy: {
    user_challenges: {
      end_date: 'desc',
    },
  },
});

But look, I'm restricting so that there's only one result of the JOIN. Is it really not an alternative? (Just doing the raw query)

@fabriciosautner I believe you can do it reverse though user_challenges making it distinct by challengeId and ordering it, then selecting the challenge from user_challenges and returning the values in a map
const result = await prisma.user_challenges.findMany({
  // In order to only get one `challenge` per `user_challenges`
  distinct: 'challengeId',

  // order the `user_challenges.end_date` by desc
  orderBy: {
    end_date: 'desc',
  },

  // includes the `challenge` in the query
  select: {
    challenge: true,
  },

  // your query
  where: {
    user_id,
    completed: true,
    is_current: true,
  },
});

const challengesFound = result.map(r => r.challenge)

repo: prisma/prisma


text:
called Option::unwrap() on a None value

Hi Prisma Team! My Prisma Client just crashed. This is the report:
Versions

Name
Version

Node
v20.4.0

OS
debian-openssl-3.0.x

Prisma Client
in-memory

Query Engine
6b0aef69b7cdfc787f822ecd7cdc76d5f1991584

Database
mongodb

Logs
prisma:client:libraryEngine sending request, this.libraryStarted: false
prisma:client:libraryEngine library starting
prisma:client:libraryEngine sending request, this.libraryStarted: false
prisma:client:libraryEngine library already starting, this.libraryStarted: false
prisma:client:libraryEngine library started

Client Snippet
// PLEASE FILL YOUR CODE SNIPPET HERE

Schema
// PLEASE ADD YOUR SCHEMA HERE IF POSSIBLE

Prisma Engine Query
{"X":true}}}

My schema:
model PromotionBlacklist {
  id        String      @id @default(auto()) @map("_id") @db.ObjectId
  userId    String      @unique
  indexData IndexData[]
}

model IndexData {
  id                 String             @id @default(auto()) @map("_id") @db.ObjectId
  channelId          String
  index              Int
  PromotionBlacklist PromotionBlacklist @relation(fields: [userId], references: [userId])
  userId             String

  @@unique([userId, channelId])
}

I got that in Prisma Studio while viewing a model. So I'd say it should be findMany() that caused the error. Also, what does it mean to give a partial dataset? And how do I do that?

I suppose that this error was originated because of a certain type of data in one of your database rows, which does not match the provided schema. Usually these are hard to reproduce so we would appreciate if you could help us reproducing it. Do you get this error consistently?

Yes, I do get this consistently. And I'd love to help you reproduce, can you guide me through?

Sure! The first thing I would do is to isolate which model produces this error. Ideally, we would get down to a simple prisma.<model>.findMany() query in a new ts/js file, that should be quick enough to try. I'd write one for each model and execute all of them to find out. If that isolates a specific table, then we need to look at the data of that table and then go deeper.

Hey @GoodBoyNeon, did you see Pierre's response above? We would like to help you out here, but need your help in reproducing this so we can understand, reproduce and hopefully fix. Thanks.

I am not able to reproduce the issue, it suddenly got fixed. I will inform if there are any updates

Thank @GoodBoyNeon, in that case, I am going to close the issue.  Thank you for getting back to use!

authors: GoodBoyNeon SevInf janpio millsp


text:
Support for Vitess

Feature Request
What feature are you missing?
Support for Vitess (https://vitess.io/)
How could this feature look like in detail? Tradeoffs?
Luckily, this would be very similar to MySQL support, with some extra work on top. Vitess is the MySQL based sharding framework used by google.

And also support Citus (https://www.citusdata.com/)

Seems like nobody cares about making Prisma extensible by adding more connectors...
How can that be?

In order for my team to continue using Prisma, we need support for at least one Cloud Native (Kubernetes) DB. Either this or CockroachDB. I strongly believe there needs to be an emphasis put on this.
Or, at the very least, an article describing best practices using Prisma with Kubernetes, including the database aspect. Prisma itself works great on Kubernetes. But I want to know how to best host the database on Kubernetes as well

Vitess supports the MySQL protocol, so it should just work. I think there might be an issue with the old MariaDB driver causing issues (https://github.com/vitessio/vitess/issues/4603). I'm hopeful that the switch to the MySQL driver in this PR https://github.com/prisma/prisma/pull/3759 will solve the connection problem.

@netspencer can you sharing you solution deploy prisma in kubernetes ?

authors: derekperkins marcus-sa meodemsao netspencer tslater


text:
Go client: prisma.Client.GraphQL() unmashal result into struct

When i run a custom query using GraphQL() I always have to use libraries like mitchellh/mapstructure to bind map values to a structure.
Adding a parameter to GraphQL() (resp interface{}) would allow to decode data directly into my struct because machinebox/graphql already supports decoding into struct
The alternative implementation would be
func (client *Client) GraphQL(ctx context.Context, query string, variables map[string]interface{}, resp interface{}) error {

	req := graphql.NewRequest(query)

	if client.Secret != "" {
		req.Header.Add("Authorization", "Bearer "+client.Secret)
	}

	for key, value := range variables {
		req.Var(key, value)
	}

	return client.GQLClient.Run(ctx, req, resp)
}

This implementation allows to work with both map and structure:
var m map[string]interface{}
err := client.GraphQL(ctx, query, vars, m)

var s MyStruct
err := client.GraphQL(ctx, query, vars, &s)

I agree with this. In particular, it is in line with the API I had in mind for raw database queries.
This is a backwards incompatible change, but I suspect we're fine with that. @timsuchanek?

I use this method to expose the feature as this point:
// GraphQL Send a GraphQL operation request
func Run(client *prisma.Client, ctx context.Context, query string, variables map[string]interface{}, resp interface{}) error {
	req := graphql.NewRequest(query)

	if client.Secret != "" {
		req.Header.Add("Authorization", "Bearer "+client.Secret)
	}

	for key, value := range variables {
		req.Var(key, value)
	}

	if err := client.GQLClient.Run(ctx, req, &resp); err != nil {
		return err
	}
	return nil
}

we could easily integrate it into the core lib without a breaking change, as shown in https://github.com/prisma/prisma-client-lib-go/pull/5

authors: chris-rock dominikh karrim


text:
Panic: Did not find a relation for model

I'm using prisma 2.13.1.
model Movie {
  id       String           @id @default(cuid())
  title    String
  slug     String           @unique
  synopsis String
  year     Int
  runtime  Int
  imdb     String           @unique
  rating   Float
  poster   String
  genres   String[]
  cast     ActorsOnMovies[] @relation("ActorsOnMovies")

  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model Actor {
  id     String           @id @default(cuid())
  imdb   String           @unique
  name   String
  movies ActorsOnMovies[] @relation("ActorsOnMovies")

  createdAt DateTime @default(now())
  updtedAt  DateTime @updatedAt
}

model ActorsOnMovies {
  actorId   String
  actor     Actor  @relation("ActorsOnMovies", fields: [actorId], references: [id])
  movieId   String
  movie     Movie  @relation("ActorsOnMovies", fields: [movieId], references: [id])
  character String

  @@id([actorId, movieId])
}

Then I run prisma db push --force --preview-feature and I get:
Running generate... (Use --skip-generate to skip the generators)
Error: Schema parsing
thread 'main' panicked at 'Did not find a relation for model Actor and field movies', libs/prisma-models/src/datamodel_converter.rs:80:29
stack backtrace:
   0: _rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: prisma_models::datamodel_converter::DatamodelConverter::convert_fields::{{closure}}::{{closure}}
   3: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   4: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   5: prisma_models::datamodel_converter::DatamodelConverter::convert
   6: query_engine::main::main::{{closure}}::main::{{closure}}
   7: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   8: std::thread::local::LocalKey<T>::with
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  10: async_io::driver::block_on
  11: tokio::runtime::context::enter
  12: tokio::runtime::handle::Handle::enter
  13: std::thread::local::LocalKey<T>::with
  14: std::thread::local::LocalKey<T>::with
  15: async_std::task::builder::Builder::blocking
  16: query_engine::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Thanks for reporting this!
To me it looks like that datamodel should not have passed validation in the first place. The relation name ActorsOnMovies  is used four times. This is invalid since it should uniquely identify one relation between two fields.
I'll see whether we need to adjust our validation steps to detect this earlier.

Thanks for reporting this!
To me it looks like that datamodel should not have passed validation in the first place. The relation name ActorsOnMovies  is used four times. This is invalid since it should uniquely identify one relation between two fields.
I'll see whether we need to adjust our validation steps to detect this earlier.

@do4gr The relation name is indeed used four times, but I didn't do that manually, it was auto-generated by the prisma formatter. The only thing I changed was the fields name.

@do4gr The relation name is indeed used four times, but I didn't do that manually, it was auto-generated by the prisma formatter. The only thing I changed was the fields name.

Probably several bugs: formatter as well as schema validator.

Probably several bugs: formatter as well as schema validator.

Hi i had similar issue. MIgrations are generated corectly.
Error
Prisma schema loaded from prisma/schema.prisma Error: Schema parsing thread 'main' panicked at 'Did not find a relation for model mldata and field alternativelmdata', libs/prisma-models/src/datamodel_converter.rs:80:29 stack backtrace:    0: backtrace::backtrace::libunwind::trace              at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86    1: backtrace::backtrace::trace_unsynchronized              at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66    2: std::sys_common::backtrace::_print_fmt              at src/libstd/sys_common/backtrace.rs:78    3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt              at src/libstd/sys_common/backtrace.rs:59    4: core::fmt::write              at src/libcore/fmt/mod.rs:1076    5: std::io::Write::write_fmt              at src/libstd/io/mod.rs:1537    6: std::sys_common::backtrace::_print              at src/libstd/sys_common/backtrace.rs:62    7: std::sys_common::backtrace::print              at src/libstd/sys_common/backtrace.rs:49    8: std::panicking::default_hook::{{closure}}              at src/libstd/panicking.rs:198    9: std::panicking::default_hook              at src/libstd/panicking.rs:217   10: std::panicking::rust_panic_with_hook              at src/libstd/panicking.rs:526   11: rust_begin_unwind              at src/libstd/panicking.rs:437   12: std::panicking::begin_panic_fmt              at src/libstd/panicking.rs:391   13: prisma_models::datamodel_converter::DatamodelConverter::convert_fields::{{closure}}::{{closure}}   14: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold   15: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold   16: prisma_models::datamodel_converter::DatamodelConverter::convert   17: query_engine::main::main::{{closure}}::main::{{closure}}   18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll   19: std::thread::local::LocalKey<T>::with   20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll   21: async_io::driver::block_on   22: tokio::runtime::context::enter   23: async_global_executor::reactor::block_on   24: std::thread::local::LocalKey<T>::with   25: async_std::task::builder::Builder::blocking   26: query_engine::main   27: std::rt::lang_start::{{closure}}   28: std::rt::lang_start_internal::{{closure}}              at src/libstd/rt.rs:52   29: std::panicking::try::do_call              at src/libstd/panicking.rs:348   30: std::panicking::try              at src/libstd/panicking.rs:325   31: std::panic::catch_unwind              at src/libstd/panic.rs:394   32: std::rt::lang_start_internal              at src/libstd/rt.rs:51   33: main
Schema
`model mldata {
id            Int  @default(autoincrement()) @id
job           job
pod           assetpod
service       service
start         Int? //changed to BigInt in migration
endf          Int? //changed to BigInt in migration
content       String? //changed to Text in migration
confidence    Float?
parents       parentmldata[] @relation(name: "ParentMlData")
alternative   alternativelmdata[] @relation(name: "AlternativeMlData")
createdat     DateTime @default(now())
updatedat     DateTime @updatedAt @default(now())
}
model parentmldata {
id            Int  @default(autoincrement()) @id
mldataid      Int
mldata        mldata @relation(name: "TheMlData", fields: [mldataid], references: [id])
parentid      Int
parent        mldata @relation(name: "ParentMlData", fields: [parentid], references: [id])
}
model alternativelmdata {
id            Int     @default(autoincrement()) @id
mldataid      Int
mldata        mldata  @relation(name: "TheMlData", fields: [mldataid], references: [id])
alternativeid Int
alternative   mldata @relation(name: "AlternativeMlData", fields: [alternativeid], references: [id])
}`

Hi i had similar issue. MIgrations are generated corectly.
Error
Prisma schema loaded from prisma/schema.prisma Error: Schema parsing thread 'main' panicked at 'Did not find a relation for model mldata and field alternativelmdata', libs/prisma-models/src/datamodel_converter.rs:80:29 stack backtrace:    0: backtrace::backtrace::libunwind::trace              at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86    1: backtrace::backtrace::trace_unsynchronized              at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66    2: std::sys_common::backtrace::_print_fmt              at src/libstd/sys_common/backtrace.rs:78    3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt              at src/libstd/sys_common/backtrace.rs:59    4: core::fmt::write              at src/libcore/fmt/mod.rs:1076    5: std::io::Write::write_fmt              at src/libstd/io/mod.rs:1537    6: std::sys_common::backtrace::_print              at src/libstd/sys_common/backtrace.rs:62    7: std::sys_common::backtrace::print              at src/libstd/sys_common/backtrace.rs:49    8: std::panicking::default_hook::{{closure}}              at src/libstd/panicking.rs:198    9: std::panicking::default_hook              at src/libstd/panicking.rs:217   10: std::panicking::rust_panic_with_hook              at src/libstd/panicking.rs:526   11: rust_begin_unwind              at src/libstd/panicking.rs:437   12: std::panicking::begin_panic_fmt              at src/libstd/panicking.rs:391   13: prisma_models::datamodel_converter::DatamodelConverter::convert_fields::{{closure}}::{{closure}}   14: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold   15: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold   16: prisma_models::datamodel_converter::DatamodelConverter::convert   17: query_engine::main::main::{{closure}}::main::{{closure}}   18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll   19: std::thread::local::LocalKey<T>::with   20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll   21: async_io::driver::block_on   22: tokio::runtime::context::enter   23: async_global_executor::reactor::block_on   24: std::thread::local::LocalKey<T>::with   25: async_std::task::builder::Builder::blocking   26: query_engine::main   27: std::rt::lang_start::{{closure}}   28: std::rt::lang_start_internal::{{closure}}              at src/libstd/rt.rs:52   29: std::panicking::try::do_call              at src/libstd/panicking.rs:348   30: std::panicking::try              at src/libstd/panicking.rs:325   31: std::panic::catch_unwind              at src/libstd/panic.rs:394   32: std::rt::lang_start_internal              at src/libstd/rt.rs:51   33: main
Schema
`model mldata {
id            Int  @default(autoincrement()) @id
job           job
pod           assetpod
service       service
start         Int? //changed to BigInt in migration
endf          Int? //changed to BigInt in migration
content       String? //changed to Text in migration
confidence    Float?
parents       parentmldata[] @relation(name: "ParentMlData")
alternative   alternativelmdata[] @relation(name: "AlternativeMlData")
createdat     DateTime @default(now())
updatedat     DateTime @updatedAt @default(now())
}
model parentmldata {
id            Int  @default(autoincrement()) @id
mldataid      Int
mldata        mldata @relation(name: "TheMlData", fields: [mldataid], references: [id])
parentid      Int
parent        mldata @relation(name: "ParentMlData", fields: [parentid], references: [id])
}
model alternativelmdata {
id            Int     @default(autoincrement()) @id
mldataid      Int
mldata        mldata  @relation(name: "TheMlData", fields: [mldataid], references: [id])
alternativeid Int
alternative   mldata @relation(name: "AlternativeMlData", fields: [alternativeid], references: [id])
}`

We improved validation and the formatter a lot in the last few releases. Please try again with 2.18.0 or later, and open a new issue if you notice anything wrong. Thanks for reporting!

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["mongoDb", "fullTextSearch"]
}

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}

model editedmessages {
  id          String   @id @default(auto()) @map("_id") @db.ObjectId
  userId String
  oldMessage String
  newMessage String
  editDate String
  messageID String
  user   users   @relation("users", fields: [userId], references: [userId], onDelete: NoAction, onUpdate: NoAction)
  users  users[]
}

model stafftags {
  id          String   @id @default(auto()) @map("_id") @db.ObjectId
  v           Int      @map("__v")
  fullMessage String
  type        String[]
  userId      String
}

model statistics {
  id    String @id @default(auto()) @map("_id") @db.ObjectId
  v     Int    @map("__v")
  date  String
  total Int
  type  String
}

model users {
  id               String           @id @default(auto()) @map("_id") @db.ObjectId
  v                Int              @map("__v")
  avatarURL        String
  firstMessage     String
  lastMessage String?
  userId           String           @unique(map: "userId_1")
  username         String           @unique(map: "username_1")
  statistics       userstatistics   @relation(fields: [userId], references: [userId])
  userstatistics   userstatistics[] @relation("users")
  message       editedmessages   @relation(fields: [userId], references: [userId])
  editedmessages   editedmessages[] @relation("users")
}

model userstatistics {
  id     String  @id @default(auto()) @map("_id") @db.ObjectId
  v      Int     @map("__v")
  total  Int
  userId String
  user   users   @relation("users", fields: [userId], references: [userId], onDelete: NoAction, onUpdate: NoAction)
  users  users[]
}

model webusers {
  id       String  @id @default(auto()) @map("_id") @db.ObjectId
  username String
  password String
  email    String
  admin    Boolean
}

Throws an error,
❯ npx prisma format
Prisma schema loaded from prisma\schema.prisma
thread '<unnamed>' panicked at 'Did not find a relation for model users and field editedmessages', query-engine\prisma-models\src\builders\internal_dm_builder.rs:122:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Unexpected token D in JSON at position 0

I split this into a new issue @schwarzsky: https://github.com/prisma/prisma/issues/13193

authors: albertoperdomo brielov do4gr janpio mic1983 schwarzsky tomhoule