Closed michielbdejong closed 3 years ago
Thanks for the code, I'll only update slugs with null values and make sure to use the same system as the ruby code above
const { Client } = require('pg');
const dotenv = require('dotenv');
dotenv.config();
const client = new Client({
connectionString: process.env.DATABASE_URL,
ssl: {
rejectUnauthorized: false
}
});
client.connect();
client.query('SELECT * FROM services WHERE slug is null', (err, res) => {
if (err) throw err;
for (let service of res.rows) {
let slug = (service.slug || service.name.split(' ').join('').split('.').join('-').split('/').join('_').toLowerCase());
console.log("Generated slug for", service.name, "-", slug);
client.query('UPDATE services SET slug = $1 WHERE ID = $2', [slug, service.id], (err, res) => {
if (err) throw err;
console.log("Service slug updated!")
});
}
});
Code above which uses the same system as ruby :-)
Worked perfectly.
We use the Service slug in edit.tosdr.org to determine the filename in tosdr.org. Sometimes, it's stored explicitly in postgres, sometimes it's inferred on the fly, see: https://github.com/tosdr/edit.tosdr.org/blob/master/db/export_services_to_old_db.rb#L18
@JustinBack do you also need the slug for beta.tosdr.org? You asked if it makes sense to just always store the slug in the database, so the code for export / API becomes simpler.
Sure, go for it! Just make sure that you use that existing code to generate the slug you store, otherwise the export script will create duplicate services (one with the old slug that was generated on-the-fly, and one with the new slug which you stored explicitly).