[i18nIgnore] feat: remove Astro Studio references

[casungo]

This PR removes any Astro Studio reference since the platform is being sunset.
It needs to be evalued if a notice + mini-guide for migration should be included till the very end of the platform (in like 1 year).

[netlify]

✅ Deploy Preview for astro-docs-2 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	b948f51
🔍 Latest deploy log	https://app.netlify.com/sites/astro-docs-2/deploys/6703c13a63043f0008c9577d
😎 Deploy Preview	https://deploy-preview-9509--astro-docs-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[astrobot-houston]

Lunaria Status Overview

🌑 This pull request will not trigger status changes.

Learn more

Lunaria automatically ignores changes on specific PRs by adding a ignored keyword in its title. Found: i18nIgnore.

You can change this by either removing the keyword above from the PR's title, or modifying the ignoreKeywords property in your Lunaria configuration file.

Tracked Files

Note

The notes below indicate what would happen if the pull request is merged when triggering status changes. Since a ignored keyword was found in the PR's title, the status changes indicated below won't be applied.

Locale	File	Note
en	guides/astro-db.mdx	Source changed, localizations will be marked as outdated.
en	guides/integrations-guide/db.mdx	Source changed, localizations will be marked as outdated.
en	reference/cli-reference.mdx	Source changed, localizations will be marked as outdated.
it	guides/astro-db.mdx	Localization changed, will be marked as complete.
ja	guides/integrations-guide/db.mdx	Localization changed, will be marked as complete.

Warnings reference

Icon	Description
🔄️	The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

[Fryuni]

Awesome start! Left some ideas on how the pages could be changed. Nothing set in stone tho

[sarah11918]

Thank you @casungo for kicking this off, and thanks for jumping in early @Fryuni !

I love where this is going, how you've already realized that the existing structure was a result of the various parts that were added at different times, and want to emphasize that we have TOTAL CONTROL over where this page goes now.

One bit of context from the original page: we really did need to keep "Astro DB" stuff separate from "Studio" stuff, which meant explaining as much of the Astro DB stuff first, and then thinking about "connecting to your database" as something separate and difference. But maybe looking at the process as a whole, that's not the way people think of "using a database" in their project, and we don't have to be beholden to any of the original structure!

In light of that flexibility, some things I knew I would consider:

• Is it more likely that people will be starting/creating new databases from scratch, or might you have existing data that you want to connect with? There may be a world where you start by hooking up a database you already have vs. waiting halfway down this page. e.g. If you have a database, maybe it feels weird to talk about creating mock data to seed so you have access to the "shape" of data for working in dev and testing without acknowledging the data you have, or whether you can seed a copy of production data for working with?

• We received feedback on this initial page that people were working through all the sections like "steps" (rather than treating them as explanations of each step in the process) and would complain about errors when trying to use all the code samples together, as if they should have worked with each other. (Which was never the intention. We did not create a walk-through of an entire process.) As a result, when we wrote the Actions page, we did start with a very basic "Write your first action!" that didn't take too long, and did give people something self-contained to walk through before describing the parts of the process. I had wondered whether using this Actions page as a model in that respect might work well here. Just the smallest overview of something working, and then the examples we'd use in sections throughout the page (like creating references) could assume/refer back to that initial example.

[casungo]

First off thank you for the comment, gave me a new perspective on how to approach this

• Is it more likely that people will be starting/creating new databases from scratch, or might you have existing data that you want to connect with? There may be a world where you start by hooking up a database you already have vs. waiting halfway down this page. e.g. If you have a database, maybe it feels weird to talk about creating mock data to seed so you have access to the "shape" of data for working in dev and testing without acknowledging the data you have, or whether you can seed a copy of production data for working with?

• We received feedback on this initial page that people were working through all the sections like "steps" (rather than treating them as explanations of each step in the process) and would complain about errors when trying to use all the code samples together, as if they should have worked with each other. (Which was never the intention. We did not create a walk-through of an entire process.) As a result, when we wrote the Actions page, we did start with a very basic "Write your first action!" that didn't take too long, and did give people something self-contained to walk through before describing the parts of the process. I had wondered whether using this Actions page as a model in that respect might work well here. Just the smallest overview of something working, and then the examples we'd use in sections throughout the page (like creating references) could assume/refer back to that initial example.

I think that we should "guide" the user, at least trough the initial setup to have them in the mindset that once you set 2 env variables you are good and the rest of the things to do are either to seeds your database from zero or to copy how your database is already structured. The actions doc is a great writeup and I think by borrowing a few aspect of it the db page will feel like a page for a completly new feature (not that db is old, or maybe it is old by astro standards where if you blink you miss 3 major releases of everything)

Based on this, I think that the page should have a structure like this:

Overview
Installation
Basics
 Get started with a fresh database
 Use an already existing database
libSQL connection configuration options
Defining your database
 [keep it as it is]
Seeding your database
 [keep it as it is]
Querying your database
 [keep it as it is]
Basic commands
 Pushing data
 Pushing table schemas
 [etc...]
Building Astro DB integrations
 Type safe operations in integrations
Self-hosted production deployment

[sarah11918]

I love that idea for a structure! Would you be up for taking a shot at reorganizing it yourself?

[casungo]

Currently I'm on vacation till next Monday so I doubt I can draft something up these days, but after this week I'll tackle this for sure (or if someone precedes me i can review the changes) :)

[sarah11918]

Oh, no worries! Enjoy your vacation! Let's see what we've come up with by the time you're back!

[sarah11918]

Alright! I took a shot at this, trying to think of a reasonable process re: how you might think of this. Completely open to thoughts and suggestions!

Note, since we're going to merge this soon, to the main branch, we should keep the "Migrate from Studio" up for a while longer, just in case it's helpful to people who are still migrating. I would have to check on the exact date, but I think people will still have access for a while yet (maybe can't make new DBs etc, but at least to get their data)

[ArmandPhilippot]

Looks good to me as someone who's never used Astro Studio nor Astro DB! Just a tiny typo.

I still have an interrogation. From what I understand, in development mode, there is nothing to configure: Astro takes care of generating a database from two files (db/config.ts and db/seed.ts)... but generate where? Is a .db file generated in the db directory or in .astro/? Do I have access to it? Can I see how the data is generated?

My question may be stupid, as I said I am not used to Astro DB, but from where I stand I tell myself that it could be important information if someone needs to debug code related to their database. Maybe this scenario never happens... and I'm just curious to better understand how it works locally. 😄 So would it make sense to specify this information in the documentation?