Stripe / Payload CMS integration...
I'm trying to configure a next.js project with both Stripe and Payload.
Stripe needs access to table header columns id. If i do Postgres, it forces a header column name of xata_id. Payload requires a Postgres enabled DB. I've gotten a schema to work perfectly via Neon, but I'm trying to use Xata as my db. I've gotten past all the "malformed schema file" issues and now it's just giving me one of two errors. Either the migration errors out or theres a runtime error when requesting data from Payload. I'm initiating brand new DB's as such:
When I try to apply the above migration into the xata main branch, it says:
So I Changed the colums with id to xata_id and set up a db with Postgres set to false. The migration worked flawlessly, but there is now error when i run the app and it pulls data from Payload.
Below is the Schema file. @NiCK (My friend)
7 Replies
Schema File:
Hi, you mean you are using a database with Postgres enabled right? (since this schema is clearly from a Postgres DB).
The error output isn't very informative unfortunately. Can you provide your workspace ID and the branch name (database:branch) so we can check our logs for any potential errors?
Also, just to clarify, did you set the Xata postgres endpoint of your database as the connection endpoint in Payload?
@kostas Yeah, I tried both. When selecting a db with Postgres enabled, it doesn't give any error with the Schema file. It just asks if I want to apply the migration into the main branch. When I select yes, it says: "Error: this endpoint works only with non postgres
enabled branches". Workspace Id: Michael-Martell-s-workspace-ec029j I gave support access as well. branch is main.
Right, that is so by "design". Schema files cannot be imported in Postgres databases, as they don't use Xata's Schema Apply endpoint any more. Postgres-enabled databases support standard postgres tooling instead to export/import schema and data (reference: https://xata.io/docs/postgres#export)
You'd have to manually create the schema from scratch to use such a database. Or, apply it from an ORM or other migration system that manages Postgres schema (I am not sure if Payload does that?).
Regarding connecting with Payload, can you provide a ballpark timestamp when you tried to connect but failed? Would that be around 13:00 UTC? I see some failed statements at that time on your workspace. If you try it again, can you please let me know of the timestamp?
Also, if you can share the configuration part where you set Xata as the Postgres endpoint (careful don't reveal the api key!) it would help to confirm how things are currently set up.
@kostas . I’ve tried connecting on several different setups. The closest I got was using the payload 3.0 template (on their GitHub) with a brand new Postgres db. Without defining a schema file, and simply by init-ing the payload setup (endpoint) it did create the appropriate tables but xata said that the tables needed to be configured for use. (Renaming headers to fit the xata Postgres “mold”), which renders Payload unusable (seemingly - without modifying their framework).
Are there any projects you know of that have successfully integrated Payload using Xata Postgres and if not, developing an adapter to Integrate Payload would be incredible.
Thanks for your efforts in making things work. I gave the Payload 3.0 template a go and found some issues related to the use of anonymous code blocks, which are not allowed in our shared environment (standard Free/Pro plans).
To go into a bit more detail, Xata databases run on shared infrastructure. That's how we achieve great economy of scale and are able to offer resources on a very competitive pricing model. To grant multitenant access securely, we implement an inspection layer which ensures there's no crosstalk between users (more details about the architecture here: https://xata.io/blog/serverless-postgres-platform). Anonymous code blocks (DO statements) add an extra layer of complexity and require deeper inspection so we haven't allowed these yet on shared infrastructure until we're absolutely certain we have all the rules in place to ensure they're safe to use.
That said, this restriction with anonymous code blocks does not apply on Dedicated clusters, which are explicitly used by a single workspace.
You can find more information on Dedicated clusters here: https://xata.io/blog/postgres-dedicated-clusters. This project is currently in closed Beta, you can use the link in that blog post to request early access. If you do, we should be able to grant you access within this month.
As for the "Adapt table" step which adds custom columns: xata requires the xata_* internal fields in order to activate our added features that are not standard Postgres functionality, such as the UI, Search, File attachments etc. You can still use Xata as a pure postgres database, without adapting your tables. As we've noticed that this adapt step is problematic for several clients (ORMs and Apps that expect the schema doens't deviate from what they define) we're currently working on a small refactoring to make things work without any of our internal columns. I don't have an estimate for this release, but it's probably going to be available next month. This, combined with Dedicated Clusters, should solve all the issues you're hitting with Payload currently.
Thats amazing!! appreciate your hard work!