Integrate Existing User Databases
note
PayString was previously known as PayID.
If you have an existing user database, you can take the following steps to integrate PayString functionality into your product.
#
Extend existing database tables with new columnsThe PayString account schema is used to define a table for users.
The account table contains two fields: id
and pay_id
. The address table uses a foreign key column called account_id
which depends on id
as a foreign key to associate addresses with individual accounts. The second column is pay_id
which is where we store the string identifier (such as alice$wallet.com
).
With an existing user database, you will need to add the pay_id
column. Your user database might already have the equivalent of an id
field, but if not, add this column so that each address can reference a specific user.
The PayString account schema has three constraints that could be useful to apply to your existing user database. Two constraints guarantee that all entered PayStrings are lowercase and are not empty strings. The final and most important constraint is that the regex constraint valid_pay_id guarantees that all entered PayStrings are in compliance with the format outlined in the PayString whitepaper.
The PayString address schema is used to define a table of addresses associated with users.
Whenever a PayString is queried, the payment network and environment are sent via an Accept header. Therefore, it is important that each address stored has an associated payment network and environment. For example, upon receipt of the accept header application/xrpl-testnet+json
you should query your address table for the address associated with the xrpl
payment network and testnet
environment.
#
Match column names in data access functionsAll functions that query the database are located in src/data-access. If you use column names that do not match the schema, then you must reflect those changes in the data access functions. The following table lists the files contained within src/data-access and the corresponding column names they use:
File name | Columns used |
---|---|
payIds.ts | address.payment_network, address.environment, address.details |
reports.ts | address.payment_network, address.environment |
users.ts | account.pay_id, account.id, address.account_id, address.payment_network, address.environment, address.details |
#
Change the type of databaseThe reference implementation described in Getting Started uses a Postgres database. To use a different type of database, either update the settings in the knexfile, or replace the use of knex
throughout the repository with your preferred database connection tool.
#
Set environment variablesPayString depends on environment variables. All of these environment variables are read in src/config.ts and assigned to variables. During integration, look through all of the environment variables used in src/config.ts to ensure all are set properly for your environment.
#
Update database migrationsIf you use your own database, there are migration files written specifically for the tables outlined in src/db/schema. Either remove these migration files, or update them to match your database.
#
Update SQL filesThe .sql
files within src/db are each executed by the function syncDatabaseSchema
located in db/syncDatabaseSchema.ts. To integrate into an existing system, be sure to look through the directories in src/db to identify any .sql
files that you need to modify to fit your existing system, or to remove because they do not apply.