2012-07-19 18 views
11

Zajmuję ten kawałek oprogramowania w węzeł i MongoDB, w którym w zasadzie chcesz przechowywać wersje pakietów z następującą strukturą:Jak radzić sobie z kropkami w nazwach kluczy MongoDB?

{ 
    "versions": 
    { 
     "1.2.3": { stuff } 
    } 
} 

(podobny do sposobu npm robi rzeczy na kanapie)

Problem polega na tym, że kiedy aktualizowałem MongoDB, odkryłem, że nie pozwala to na kropki w nazwach kluczy (ze względu na istniejącą notację kropkową), co powoduje błąd mojego kodu. Po zbadaniu tego wszystkiego, jedyne, co mogłem znaleźć, to to, że musisz przekształcić kropki na inną postać przed zapisaniem w bazie danych, a następnie przekształcić je z powrotem podczas uzyskiwania dostępu. Czy naprawdę nie ma lepszego sposobu, aby sobie z tym poradzić?

Jeśli nie jest, w jaki sposób mogę wykonać tę transformację bez kopiowania danych na inny klucz i usuwania oryginału?

+0

Czy mówisz, że masz już takie dane w Mongo? To nie powinno być możliwe nawet przed aktualizacją. Z jakiej wersji korzystałeś? – Thilo

+0

@Thilo Tak naprawdę nie pamiętam, ale mógł to być sterownik, który był błędny i zezwolił na to. – jli

+0

@ c0deNinja To pozwala mi sprawdzić nazwę wersji bez iteracji przez całą gamę potencjalnie bardzo wielu wersji. – jli

Odpowiedz

2

ograniczenia Dot obecnie kierowca egzekwowane, a nie wszyscy kierowcy uniemożliwiły kropki w nazwach pól od początku. Możesz napisać nieprzetworzony kod protokołu, aby robić różne rodzaje szalonych rzeczy w Mongo, w tym używać naprawdę dziwnych postaci w nazwach kolekcji.

Będziesz o wiele lepszy, jeśli to wyczyścisz (prawdopodobnie zamień kropki na - lub inny poprawny znak), ale trudno będzie zrobić to dobrze przy każdym inteligentnym filtrowaniu. Najprawdopodobniej będziesz musiał powtórzyć całą kolekcję, zlikwidować wartości w swojej aplikacji, a następnie zastąpić całe pole "wersje" w swoim dokumencie. Zastąpione na miejscu powinno to być rozsądnie szybkie, ponieważ nie zmieni rozmiaru dokumentu i prawdopodobnie nie zmieni żadnych indeksów.

+0

Tak właśnie to wymyśliłem. Jednym z problemów jest to, że użytkownicy tej aplikacji mogą dodać dowolny ciąg jako wersję, więc nie mam standardu, z którym można pracować. Czy zmniejszenie prędkości z wykonywania tych operacji na każdym czytanym stanowisku przewyższa korzyści związane z wydajnością mongo w porównaniu z czymś w rodzaju kanapy? Mogę po prostu zmienić bazy danych, ponieważ projekt jest już w bardzo wczesnym stadium rozwoju. – jli

+0

Właściwie to wydaje się, że będzie stosunkowo szybko po testowaniu, dziękuję. – jli

+0

Czy rzeczywiście potrzebujesz zapytania w wersjach dokumentu? Można faktycznie przechowywać ciąg json w "wersjach" i po prostu sparsować go ręcznie w czasie ładowania/oglądania. Przetwarzanie ciągów na odczytach prawdopodobnie nie spowolni cię zbytnio, prędkość odczytu w Mongo jest znacznie większa niż w Couch. – MrKurt

3

Czy możesz użyć kolekcji wersji z rzeczami?

odczuwalna:

{ 
    "versions": 
    [ 
       { 
        "version_num": "1.2.3", 
        "stuff": { stuff } 
       }, 
       { 
        "version_num": "1.2.4", 
        "stuff": { stuff } 
       } 
    ] 
} 
+0

Cóż, poza tym, że jest to nieważny obiekt, ja ' Próbuję uniknąć konieczności iteracji w tablicy tutaj. – jli

+0

Tak, jest nieprawidłowy, zastanawiam się, czy tablica będzie działać. Okey – keaplogik

Powiązane problemy