ValidationException: Unexpected from source

TL;DR — PartiQL FROM cümlenizdeki tablo adı, ayrıştırıcının çıplak kabul etmeyeceği karakterler içeriyor — genellikle bir tire. Adı çift tırnak içine alın (SELECT * FROM "my-table"). Tek tırnaklar çalışmaz: PartiQL'de bir tanımlayıcı değil, bir dize literalini ifade ederler.

Ne anlama gelir

ValidationException: Unexpected from source

PartiQL ayrıştırıcısı, FROM my-table'ı my tanımlayıcısının ardından beklenmeyen belirteçler olarak okur — tire, çıplak bir tanımlayıcının içinde geçerli değildir. DynamoDB tablo adları meşru biçimde -, . ve _ içerebilir, dolayısıyla gayet geçerli bir tablo adı, tırnak içine alınana kadar PartiQL'de yine de ayrıştırılamaz olabilir. Aynısı PartiQL anahtar sözcükleriyle çakışan adlar için de geçerlidir.

Neden olur

Tablo adı bir tire ya da nokta içeriyor — users-prod, app.events. Çıplak tanımlayıcılar onları taşıyamaz.
Çerçeve tarafından üretilen tablo adları — tablo adına bir ortam ya da aşama ekleyen araçlar (örneğin Todo-dev), sen seçmeden bir tirenin girmesinin klasik yoludur.
Bir indeksi tırnak olmadan sorgulamak — "table"."index" biçimi her iki parçanın da etrafında çift tırnak gerektirir.
Çift yerine tek tırnak — FROM 'my-table' de başarısız olur: tek tırnaklar PartiQL'de bir ad değil, bir dize literalini ifade eder.

Nasıl düzeltilir

Tablo adını çift tırnak içine alın:
```
SELECT * FROM "users-prod" WHERE pk = 'USER#42'
```
Bir indeksi sorgularken her iki parçayı da çift tırnak içine alın:
```
SELECT * FROM "users-prod"."email-index" WHERE email = 'ada@example.com'
```
Tek tırnakları yalnızca dize değerleri için tutun — adlar çift tırnakta, değerler tek tırnakta. Onları karıştırmak tam olarak bu tür ayrıştırma hatasını üretir.
Üretilen ifadelerde savunmacı tırnak kullanın — kodunuz tablo adlarını PartiQL'e enterpole ediyorsa, onları her zaman çift tırnaklı yayın; ad kesin olarak buna ihtiyaç duymasa bile geçerlidir.

DynoTable'ın PartiQL düzenleyicisi, tanımlayıcı tırnaklamasını senin için ele alır — tam da bu sınıftaki ayrıştırma hataları için satır içi tanılar ve hızlı düzeltmelerle — ve DynamoDB Expression Builder, PartiQL ayrıştırmasını tamamen atlamayı tercih ettiğinizde eşdeğer yerel Query/Scan isteğini gösterir.

DynoTable'da çalıştırın

FROM kaynağı bir tablo adı olmayan bir PartiQL ifadesi. Ayrıştırıcı, bir tabloyu aramaya bile başlamadan onu reddeder; bu yüzden bu, herhangi bir uç noktada yeniden üretilebilir:

await client.send(new ExecuteStatementCommand({Statement: 'SELECT * FROM 123'}));

Gerçek çıktı:

ValidationException: Unexpected from source
HTTP 400

Bunu tırnaksız ama başka türlü geçerli bir adla karşılaştırın: SELECT * FROM repro sorunsuz ayrıştırılır ve böyle bir tablo yoksa daha sonra ResourceNotFoundException ile başarısız olur. Unexpected from source kesinlikle bir ayrıştırma hatasıdır; dolayısıyla onu eksik tablo değil, söz dizimi sinyali olarak okuyun.

Kaynaklar

PartiQL select statements for DynamoDB (2026-07-13 tarihinde doğrulandı)
Supported data types and naming rules (2026-07-13 tarihinde doğrulandı)

Nasıl yeniden oluşturulur

DynoTable'in PartiQL editörü tablo ve dizin adlarını otomatik olarak çift tırnak içine alır; ifadeyi SDK koduna yapıştırmadan önce SELECT * FROM "my-table"'yi satır içi tanılamayla çalıştırın. Kenar çubuğundan tam tablo adını (tireler dahil) onaylamak için tabloyu ⌘K ile açın.

PartiQL ayrıştırma sürekli başarısız olduğunda eşdeğer yerel istek için Query Builder'e geçin. Ayarlar → Profiller'deki profil değiştirme (⌘P) ve Bağlantıyı Test Et, ifadenin sağ tabloya yönlendirilmesini sağlar. Bkz. Connect to AWS ve Install.

İlgili hatalar

DuplicateItemException — mevcut bir anahtarda PartiQL INSERT.
ValidationException — üst istisna sınıfı.
Öğrenin: PartiQL examples · SQL for DynamoDB

Kaynaklar

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.

2026-07-26 tarihinde AWS SDK for JavaScript v3.1095.0 ile DynamoDB Local 2.x'e karşı yeniden üretildi — yukarıdaki çıktı birebir alınmıştır.