(The fix is likely that `pages dev` should use the UUID of the DB, but it doesn’t know it…)

(The fix is likely that

pages dev

pages dev

should use the UUID of the DB, but it doesn’t know it…)

MMatt Silverlock (The fix is likely that `pages dev` should use the UUID of the DB, but it doesn’...

Matt SilverlockOP•6/3/23, 9:50 PM

The binding name isn’t a stable ID, which would be the “easy” hack but break any time you renamed a binding

hanpolo•6/3/23, 9:53 PM

Created issue: https://github.com/cloudflare/workers-sdk/issues/3400

GitHub

🐛 BUG: location from d1 migration cannot match location from pages ...

Which Cloudflare product(s) does this pertain to? D1, Pages, Wrangler What version of Wrangler are you using? 3.0.1 What operating system are you using? Mac Describe the Bug We have a problem for l...

hanpolo•6/3/23, 9:53 PM

Yep .. would be happy if both worked off of UUID, but pages dev does not have a way of identifying UUID, unless it was able to read wrangler.toml

hanpolo•6/3/23, 10:02 PM

@elithrar Thanks for your help on the weekend.

Original message was deleted

Matt SilverlockOP•6/3/23, 11:26 PM

That’s fine for

wrangler d1

wrangler d1

but not

pages dev

pages dev

Original message was deleted

Matt SilverlockOP•6/4/23, 1:00 AM

Yeah, but folks change bindings, so it’s likely to be a surprise when you change a binding name -> all of your local state is “gone”.

kian•6/4/23, 1:25 AM

The irony is that if you use

wrangler.toml

wrangler.toml

which

pages dev

pages dev

picks up as a mistake then it sounds like it'd work properly meowlul

hanpolo•6/4/23, 4:08 AM

Honestly, I would much rather use wrangler.toml for pages dev. It would simplify things a lot and allow me not to have all my config on the command line. If there were some sort of switch on pages dev that said get your config from wrangler.toml that would then accommodate people who want to do it the old way.

Ssumé ሱሜ I have created a d1 database locally ``` --incidents.sql CREATE TABLE incidents...

itsmatteomanf•6/4/23, 12:17 PM

It's returned as text, you need to parse it again.

itsmatteomanf•6/4/23, 12:18 PM

You can also just get the single column, given your data structure, and parse it just once.

itsmatteomanf•6/4/23, 12:19 PM

But also, you might just put those in separate columns, they make more sense. Why you chose to put a single JSON string?

itsmatteomanf•6/4/23, 12:21 PM

As long as it's known columns, just parse it out...?

itsmatteomanf•6/4/23, 12:22 PM

It's so much easier to filter and get things. You'll get an actually valid JSON structure automatically first, without double parsing.

itsmatteomanf•6/4/23, 12:22 PM

When you get the JSON. Put the

city

city

in the

city

city

column,

date

date

in the date column, etc.

itsmatteomanf•6/4/23, 12:23 PM

Yeah, like dbs are supposed to be used

itsmatteomanf•6/4/23, 12:24 PM

JSON structures are helpful for unstructured data, but if the fields are static it's the best course of action.

Ssumé ሱሜ Haha ok, that shouldn't be too hard. And why I query it?

itsmatteomanf•6/4/23, 12:24 PM

"why"...? I'm not following the question.

itsmatteomanf•6/4/23, 12:25 PM

Oh, I see

itsmatteomanf•6/4/23, 12:26 PM

Normal SQL

env.mydb.prepare('SELECT * FROM incidents').all()

env.mydb.prepare('SELECT * FROM incidents').all()

itsmatteomanf•6/4/23, 12:27 PM

This returns a JSON array of rows, just iterate over them and get each object.

itsmatteomanf•6/4/23, 12:28 PM

Of course, if you wanted only incidents from 2017, you could filter them before getting the results

env.mydb.prepare("SELECT * FROM incidents WHERE year = '2017'").all()

env.mydb.prepare("SELECT * FROM incidents WHERE year = '2017'").all()

itsmatteomanf•6/4/23, 12:29 PM

But also, you might not even need to store years/months/days separately. There are

datetime()

datetime()

functions which allow you to filter if needed

itsmatteomanf•6/4/23, 12:29 PM

And I'd store them as numbers, regardless so you can do ranges easily

Ssumé ሱሜ Ohh nice. I'll try it out, thanks!

Matt SilverlockOP•6/4/23, 3:29 PM

You can also mix and match - https://developers.cloudflare.com/d1/learning/querying-json/

parse the JSON within D1 before returning it to your client.

Query JSON · Cloudflare D1 docs

D1 has built-in support for querying and parsing JSON data stored within a database. This enables you to:

Matt SilverlockOP•6/4/23, 3:31 PM

SELECT
  json_extract(incidents, '$.incident.city') as city
FROM
   …
WHERE
  city = "CHI"

SELECT
  json_extract(incidents, '$.incident.city') as city
FROM
   …
WHERE
  city = "CHI"

Also see

->

->

and

->>

->>

as shorthand -

SELECT incidents ->> '$.incident.year' FROM …

SELECT incidents ->> '$.incident.year' FROM …

returns plain SQL instead of JSON.

Matt SilverlockOP•6/4/23, 3:46 PM

And indexes on fields within your JSON objects: https://antonz.org/json-virtual-columns/

JSON and virtual columns in SQLite

Faster JSON handling in a relational database.

JJason Hostetter Are there any plans to increase the maximum expression depth of 20? I am refacto...

Matt SilverlockOP•6/4/23, 6:12 PM

Yes, but not > 100 at this stage. I’d like to get a better understanding of your actual query’s depth (which is non-trivial - the query planner doesn’t output it)

Murder Chicken•6/4/23, 8:49 PM

Anyone know of any simple ORMs that are compatible with D1?

MMurder Chicken Anyone know of any simple ORMs that are compatible with D1?

meyer•6/4/23, 8:51 PM

documentation: https://developers.cloudflare.com/d1/platform/community-projects/

Community projects · Cloudflare D1 docs

During D1’s alpha period, members of the Cloudflare developer community have made some valuable contributions to the D1 ecosystem. Below are some …

Mmeyer documentation: https://developers.cloudflare.com/d1/platform/community-projects/

Murder Chicken•6/4/23, 8:55 PM

Thank you! Super-helpful!

Ssteida Inconsistent unit of size in Cloudflare dashboard. KB and kB actually have diffe...

Matt SilverlockOP•6/4/23, 9:55 PM

We should be consistent, but kB and KB are the same. KiB (kibibyte) is the different unit

Ssteida ChatGPT told me it's 1000 vs 1024, but it's well-known liar so... 😅

Leon338•6/4/23, 11:58 PM

It deppends on the capitalized B. A small kb is 1000 Bit and a big kB is 8000 Bit. You can ignore the K

Unsmart•6/5/23, 12:16 AM

Afaik kb and KB are exactly the same its only KiB that is different... KB = 1000 KiB = 1024

Unsmart•6/5/23, 12:18 AM

Ah yup can be confirmed here: https://physics.nist.gov/cuu/Units/binary.html

UUnsmart Ah yup can be confirmed here: https://physics.nist.gov/cuu/Units/binary.html

Hello, I’m Allie!•6/5/23, 10:04 AM

Just make it simple, and write out the number of bits

nejc•6/5/23, 10:22 AM

Sharing if someone else is trying to figure out why worker deployment via API is not working for D1. Not sure for what reason, but you need to add __D1_BETA____D1_BETA__ infront of your binding name. Something like this:

metadata.bindings.push({
      name: `__D1_BETA__${db.name}`,
      type: 'd1',
      id: db.id,
})

metadata.bindings.push({
      name: `__D1_BETA__${db.name}`,
      type: 'd1',
      id: db.id,
})

then you can call PUT /accounts/${accountId}/workers/scripts/${scriptName}/accounts/${accountId}/workers/scripts/${scriptName} and D1 will be successfully bind

nejc•6/5/23, 10:22 AM

hope that it helps to someone

nejc•6/5/23, 10:25 AM

@skye_31 thank you. Managed to figure it out how to deploy d1 e2e with the API, so looking good

(The fix is likely that `pages dev` should use the UUID of the DB, but it doesn’t know it…)

Similar Threads

Similar Threads

Similar Threads