ArcSDE ile Sürüm Oluşturma ne zaman yayınlanan düzenlemeler iptal edilebilir veya reddedilebilir mi?


28

ArcGIS 9.3.1 kullanıyorum ve halihazırda sürümlü olarak kaydedilmiş bir SDE coğrafi veri tabanı (bir çokgen özellik sınıfı ile) ile çalışıyorum. Sürüm oluşturmada yeniyim ve hala bazı temel işlevlerini anlamaya çalışıyorum. Şimdiye kadar, belirli düzenlemeleri bir üst sürüme gönderildikten sonra "iptal etmenin" veya "reddetmenin" mümkün olup olmadığını keşfedemedim.

Örneğin, üç sürümümüz olduğunu varsayalım: sürüm olarak kaydedildiğinde oluşturulan orijinal SDE.DEFAULT, SDE.QA (Kalite Güvencesi için) olarak adlandırılan varsayılan bir alt sürümü ve SDE adlı QA'nın bir alt sürümü .Edit1 (düzenlemelerin ilk yapıldığı yer). Eğer SDE.Edit1'in bazı özellikleri düzenlenmişse (örneğin basit tutmak için diyelim ki bir çokgen eklenmiş ve bir tane kaldırılmış) ve daha sonra SDE.Edit1 SDE.QA ile bağdaşmış ve daha sonra SDE.QA'ya gönderilmiş, daha sonra bu değişikliği geri almak için herhangi bir yolu olabilir mi? Bu soruyu takip ederek sadece bazı değişiklikleri reddetmek mümkün müdür ? Örneğin, ilk poli eklemeyi kabul etmek, ancak ikinci poli almayı reddetmek?

Söyleyebildiğim kadarıyla, düzenlemeler ana sürüme gönderildikten sonra, tüm bu değişiklikler ana sürümün "kalıcı" (daha iyi bir kelime eksikliği için) bir parçasıdır. Bu değişikliklerin hepsinin "ADD" ve "DELETE" tablolarının (genellikle "delta" tabloları olarak adlandırılır) iki tablo içinde kaydedildiğini ve orijinal FC'nin kendisini değiştirmediğini biliyorum. Bu delta tablolarını manuel olarak değiştirmeyi düşündüm, ancak bunun doğru bir çözüm olmadığını bilmek için yeterince uyarıcı buldum.

Belki de biraz çalışmayı gerektiren sürüm oluşturma anlayışımdır, ancak bir değişikliği reddetmek veya bir değişiklik yapıldığında geri almak için bir yol bulamadım. Bu bana çok garip geliyor çünkü bu, hata içeren bir yazıyı geri almanın bir yolu olmadığı anlamına geliyor. Ayrıca bu versiyonların soylarını izlemenin bir yolunu bulamıyorum (yani hangi versiyonun hangi ebeveynin çocuğu olduğu). Ben konuyla ilgilenmeme rağmen, herhangi biri ArcSDE'yi anlamamda yardımcı olabilecek herhangi bir özellikle yararlı ArcSDE referanslarını (bağlantılar, makaleler, kitaplar vb.) Biliyorsa (ve bu soruların bazılarına cevap verebilir), çok memnun olurum !


Şu ana kadarki cevaplar yardımcı olsa da (bağlantılar için teşekkür ederim), sorumun özüne hala bir cevap bulamıyorum. Yine, belki de durumun kendi yanlış anlaşılması. İşte bilmek istediğim şey:

Bir alt sürümden bir üst sürüme yapılan bir gönderiyi tersine çevirir misiniz (tersine, demek istiyorum ). Bu senaryoda, ebeveyn SDE.DEFAULT versiyonu olabilir, ancak olması gerekmiyor. Daha da iyisi, bir gönderinin bir bölümünü (örneğin, bir çokgene yapılan tek bir düzenleme) ters çevirip çevirmediğinizi bilmek ister misiniz ? Ayrıca, herhangi bir çatışma tespit edilmesine gerek olmadan bunun yapılıp yapılmayacağını da bilmek istiyorum.

Herhangi bir yerde belgelenen bu soruya (yani, "evet" veya "hayır") net bir cevap bulamamam, ArcSDE'de sürüm oluşturma ile ilgili önemli bir şeyi kaçırdığımı düşündürüyor. Ayrıca A ve D tablolarını manuel olarak kullanmaktan da kaçınmayı tercih ederim.


? version & rdbms yardımcı olur
Brad Nesom

Yanıtlar:


53

Ugh. Cevap gerçekten çok fazla ArcSDE geçmişini gerektiren karmaşık bir cevap, bu yüzden mümkün olduğunca kısa olmaya çalışacağım.

Not ESRI sitesinde bulabileceğiniz süper harika sürüm beyaz kağıdındaki bazı diyagramlara başvuracağım . Versiyonlama ile uğraşıyorsanız, dikkatlice okumanızı tavsiye ederim.

Daha sonra, bir durum (yani durum ağacındaki bir düğüm) ile adlandırılmış bir versiyon (yani bir duruma işaret eden bir etiket ) arasındaki ilişkinin ne olduğunu anlamanız gerekir .

Tipik bir veritabanı aşağıdaki durum diyagramına benzeyebilir:

tipik yay veritabanı diyagramı

Burada, veritabanında dört sürüm vardır (Sürüm A, Sürüm B, Sürüm C ve DEFAULT). Ama belki de kendimden biraz daha öndeyim. Bir devletin ne olduğu ile başlayalım .

Bir durumu bir "işlem" olarak düşünebilirsiniz - bir ya da daha çok - tabloda birkaç düzenleme içeren mantıksal bir birim . İki içerebilir geçme "FeatureClass A", bir silme "Özellik Sınıf B" ve gelen bir değiştirme "Özellik sınıfı X" için (özellikle bir silme +, bir ek). Hepsi bir arada gruplandırılmış.

Durum kimliği 0'da başlayan küçük, basit bir ArcSDE durum şemasına bakalım:

hal hareketi

0 durumundan başlarsanız ve bir düzenleme işleminde bir veya daha fazla tabloda düzenleme yaparsanız, bir alt durum 1 oluşturacak ve bunu geçerli etkin durum kimliği yapacaksınız . Ardından bir başka düzenleme grubu alt durum 2'yi oluşturur. Geri almak istiyorsanız, durum kimliğini herhangi bir şekilde değiştirmeniz gerekmez - yapmanız gereken tek şey geçerli etkin durum kimliğini 1 veya 0 olarak değiştirmektir. ne kadar geriye gitmek istersin). Bir yineleme tam tersidir - yalnızca geçerli aktif durum kimliğini ileriye doğru hareket ettirin - istediğiniz kadar ileriye doğru taşıyın.

ArcSDE sürümlerinde geri al / yinele bu şekilde çalışır.

Tamam, devam et. Bir düzenlemeyi kalıcı yapmak istediğinizi (örneğin kaydetmek istediğiniz) söyleyin. Yapmanız gereken ne? Şey, tasarruf sadece sürüm etiketini alıp belirli bir duruma ilerletmektir. Bunu damgalamak ve "A Sürümünün neye benzemesi gerektiği" demesi gibi. Böylece, ilk şemaya geri bakarsanız, bunun dört adlandırılmış versiyonunun olduğunu göreceksiniz .

  • Sürüm B devlet kimliğine işaret ediyor 1
  • Sürüm A, 3 kimliğine işaret ediyor
  • C sürümü, 5 kimliğine işaret ediyor
  • "SDE.DEFAULT" sürümü 4 numaralı kimliği gösteriyor

    Lütfen, bu şemanın, halkın inancına rağmen, sahip oldukları mantıksal ebeveyn-çocuk ilişkisi hakkında hiçbir şey söylemediğini unutmayın . İlk diyagram için mantıksal ebeveyn-çocuk ilişkisi şöyle görünebilir:

mantıksal sürüm yapısı

Bu ArcMap / ArcCatalog'da gördüğünüz ebeveyn-çocuk ilişkisidir. Amacı, hangi sürümlerle uzlaşabileceğinizi kısıtlamak . Bu noktada (haklı olarak) kendinize soruyorsunuz, neden cehenneme ihtiyacım var? Cevap, iş akışlarının versiyonlanmasında yatıyor . Görünüşe göre, insanlar oldukça uzun zamandır versiyon kullanıyorlardı ve bunları yapılandırmanın bazı tercih edilen yolları var, ancak bugün sorunuzu yanıtlamak istediğimden bu gün başka bir konu. :)

Hareketli...

Tamam, bu adlandırılmış sürümler başka ne yapar? Sıkıştırma denilen bu işlemin nasıl davrandığını etkiler .

Sıkıştırma, gerekli olmayabilecek ara durumları kapmak ve gereksiz olanları kaldırmak ve bunları birleştirmekle ilgilidir. ArcSDE sıkıştırma işlemini ArcCatalog aracılığıyla tetikleyebilir, her birini bir süre için yapan bir servis ayarlayabilir ve bazı ArcMap düzenleme işlemleri mini sıkıştırma işlemlerini tetikler (sadece kullanılan küçük dallar için).

Soldaki diyagram sıkıştırılmadan önce durum ağacını ve sağdaki sıkıştırılmadan hemen sonraki durumu gösterir:

diyagramı sıkıştır

Anlamak için önemli bir kavram (nihayet sorunuzu cevapladıktan sonra size atıfta bulunacağım), her bir devletin, üzerinde işaretli etiketleri (örn. Sürümleri) bulunan durumlar haricinde, sıkıştırılacak potansiyel bir aday olduğu anlamına gelir .

Sıkıştırmadan önce, gereksiz bazı durumlar olduğunu görebilirsiniz. Aslında, [3,4,5] şubenin tamamı kaldırıldı. 5'te adlandırılmış bir sürüm olsaydı, sonuç çok farklı olurdu.

Sıkıştırma işlemleri, artık gerek duymadığınız kayıtları kaldırarak veritabanınızda yer kazanmak için var.

Tamam, devam et.

Anlamanız gereken son kavram, uzlaştırmaktır - ki bu iki dalı etkin bir şekilde birleştiriyor.

Öyleyse ilk diyagramımıza geri dönelim. Sürüm A'yı SDE.DEFAULT ile uzlaştırmak istediğinizi söyleyin.

Tekrar özetleyelim: çeşitli durum kimliklerini işaret eden dört adlandırılmış sürüm. Bu yüzden yapmamız gereken ilk şey, hedef versiyonun altında bir çocuk devleti oluşturmaktır, bu yüzden 4 numaralı devletin altında bir çocuk devleti yaratırız, örneğimizde, bu durum kimliği 20 olarak adlandırıyorum.

uzlaştırmaya başla

Bir sonraki adım, her iki sürüm arasındaki farkları hesaplamaktır (detaylar bu gönderi için çok uzun, ama size fark imleçleriyle yapıldığını söyleyebilirim ) ve daha sonra bu farkları bu yeni durum kimliği 20'ye (mavi çizgi) uygulayarak söyleyebilirim .

uzlaştırmak

Daha fazla düzenleme yapmaya karar verdiğinizi veya çakışmalar bulduğunuzu ve bir sürümden veya diğerinden satır seçtiğinizi söyleyin. Önemli değil. Bunlar sadece yeni düzenlemelerdir ve alt birleştirdiğiniz dalın altında alt durum belirtildiği gibi bir düzenleme işlemi içinde yapılır. Bu örnekte, mutabakattan sonra iki ardışık düzenleme grubu daha yaptım.

mutabakattan sonra yapılan düzenlemeler

Güzel.

Öyleyse şimdi sürümü " posta " hazır olduğunuzu söyleyin . Bu ne anlama geliyor? Bu sadece etiketleri kapmak ve aynı durum kimliğine işaret ediyor. Burada, Sürüm A’yı SDE.DEFAULT’a göndereceğim. Göründüğü gibi:

gönderme

Tadaaa! Bu yüzden şimdi A ve SDE.DEFAULT sürümleri aynı durum kimliğine işaret ediyorlar ve aynı görünüyorlar.

Tamam, şimdi nihayet sorunuza cevap verebilirim.

Bir yazıyı geri alabilir misin? ArcGIS belgeleri size hayır diyecek - onunla uğraşma. Yapmayın, çünkü bu mantığı bozacaksınız ve ne yaptığınızı bilmiyorsanız verilerinizi bozabilirsiniz.

Fakat gerçekte, tek gereken ArcSDE Sürüm tablolarından birinin ( VERSIONS tablosu) bir güncellemesini yapmak ve etiketin girişini değiştirmek (aka sürüm adıyla). Örneğimizde, id 21 durumunu belirtin ve bu düzenleme işleminin tamamını geri aldınız. 3 olarak ayarlayın ve sadece tüm uzlaşmayı düzenlediniz. 5 olarak ayarlayın ve şimdi tamamen farklı bir yerdesiniz. Çatışma olup olmadığının önemi yoktur.

Tabii ki, bu bir sıkıştırma olmadığını varsayar. Sıkıştırmanın, SDE tablosunu güncellerken aynı anda gerçekleştiği durumu düşünelim. Unutmayın, siz - ya da başkası - siz gönderdikten sonra bir sıkıştırma uygularsa, ağaç böyle görünür:

yayından sonra sıkıştır

Kompresyondan sonra uzlaştırmayı geri alabilir misiniz? Eh, bu durumda, hayır . Sıkıştırma işlemi dalın tamamını havaya uçurdu, bu nedenle geri alamazsınız; bu veriler kaldırılmıştır. Bu dalda başka bir sürüm daha olsaydı, o zaman sıkıştırma o dalı imha edemezdi. Umarım bu şimdi anlamlıdır.

Peki bunu yapmalısın? Size bağlı olarak, ne yaptığınızı bilmiyorsanız, bir sıkıştırmadan sonra verileri kolayca kaybedebilirsiniz.


4
Harika cevap Ragi! SDE versiyonlaması karmaşık bir canavardır.
blah238

2
Teşekkürler. ArcObjects'deki mutabakat kodunu üç yıl boyunca korudum / uzattım, bu yüzden çeşitli ArcGIS sürümlerinde bu davranışı ayarlayarak oynadım. Kavramları basitleştirmek için birkaç şeyi atladım. Umarım bir cevap olarak yeterince açıktır.
Ragi Yaser Burhum

2
Bu çok ayrıntılı cevap için teşekkür ederim Ragi! Kendimi neyin içine soktuğumu daha iyi anladığımı hissediyorum. Farklı bir devlet kimliğine bir değişikliği "geri almak" (ya da belki de "geri adım atmak") için bir mekanizma olarak göstermeniz, daha uygun bir açıklama olacaktır. Verdiğiniz ArcSDE Sürüm Tablolarını hala araştırıyorum. Her durumda, tavsiyene uyacağım ve dikkatli davranacağım. Bu adım adım ilerlemek için zaman ayırdığınızdan dolayı tekrar teşekkür ederiz!
Sole23

2
+1 Bunu favorilere ekleyerek. Ben çoğu insan neden göstermektedir düşünüyorum değil SDE sürüm tablolar ile müdahalesi olması ve bu konuda düşünme olanlar öğrendiğimizde bu cevaba linki göndereceğiz!
Jay Cummins,

2
Vay, sorularımdan biri hakkında yorum yaptın ve son birkaç saatimi harcayarak yanıtladığın tüm soruları okuyarak geçirdim. Harika şeyler, teşekkürler.
ianbroad

7

ArcCatalog eklentisi olan Geodatabase Toolset (GDBT) adı verilen bir araç var. Durum linajını ve versiyonlarını görselleştirir:

GDBT'yi buradan indirin


Teşekkürler Stefan. Bu tam olarak var olmayı umduğum bir şeydi! Bu, SDE FC'imin soyunun görselleştirilmesini ve izlenmesini çok daha kolaylaştırıyor.
Sole23

2
Ayrıca, çoğu insan bunu bilmez, ancak (eyaletler tamamen sıkıştırılmadığı sürece), VERSIONS tablosuna hala geçerli olan herhangi bir devlet kimliği için bir giriş ekleyebilir ve ardından arcgis’i mutlu bir şekilde taramak, düzenlemek için kullanabilirsiniz. ve hatta standart ArcGIS araçlarını kullanarak bu sürümü bağdaştırın. Sürümler, ArcSDE'yi bu durumları hayatta tutmaya zorlayan kimlik numaralarını bildiren etiketlerdir.
Ragi Yaser Burhum

Tamam, daha ayrıntılı bir cevap vereyim.
Ragi Yaser Burhum,

3

Sürümü ve db bilmek kısa. İşte size yardımcı olacak bazı ilk bilgiler.
Temel yönetici
İşte rec ve post hakkında bazı bilgiler
Bu yüzden, bu kavramları uygular ve sürüm değişiklikleri komutunu kullanırsanız, varsayılanları kaydedip gönderdiğinizde bu değişiklikleri reddetme olanağına sahip olursunuz.

Aynı veri tabanının üç kopyası yok.
Sürümleri olan bir kopyasınız var.
Bu db'yi yönetiyorsanız, gerçekten zaman harcayacağınız (belki de para) ve tüm bunlara aşina olmalısınız. Multiuser Geodatabase için
esri sınıfı Versioned Editing Workflows ücretsizdir ve bazılarına yardımcı olacaktır.
Ancak monte edilenlerin tamamı herhangi bir sürümlü sde düzenleme iş akışını yöneten bir kişi için önerdiğim şey olacaktır.
Bu sınıf harika! Multiuser Geodatabase için Versioned Editing İş Akışlarını anlamak için .


Cevabınız için teşekkürler Brad. Tavsiye ettiğiniz linkleri ve sınıfları inceleyeceğim!
Sole23

Bu bağlantılar sql server içindir - fakat bunlara çok yakın olan diğer rdbms yardım dosyaları vardır.
Brad Nesom

1
Tavsiye ettiğiniz Esri seminerinin ücretsiz kaydını izledim: Çok Kullanıcılı Geodatabase için Sürüm Düzenleme İş Akışları . Gerçekten yararlı olduğunu ve kesinlikle izlemek için harcadığı zamana değdiğini düşündüm (~ 1 saat). Tavsiye için tekrar teşekkürler. Ben de onlar seminerde cevap zaman yoktu yani, ilave sorulara vardı yanıtları görmek için bir bağlantı bulundu burada .
Sole23

3

"Hızlı ve kirli" bir yolum var. Ove varsayılan sürüme geçin ve silinen çokgen hakkında bir şeyler düzenleyin. Ardından varsayılana bağdaştığınızda bir çatışma olur. Çatışmayı sağ tıklayın ve uzlaşma öncesi durumunu kullanmasını söyleyin. Benim için çalışıyor.


1

Evet, bunu yapabilirsin, ama bunu SQL kullanarak yapmak zorunda kalacaksın.

BU KORUMA DEĞİL, KENDİ RİSKİNİZDE BU YAPIN. HER ZAMAN, SDE'Nİ MANUEL Olarak EDİT ETMEDEN ÖNCE VERİLERİNİZİ YEDEKLEME.

Sde.versions tablosunu sorgulayarak, geri almak istediğiniz değişikliklerle birlikte yayınladığınız sürümden state_id değerini alabilirsiniz. Sonra A ve D tablolarına gidip state_id ile eşleşen girişleri silebilirsiniz.

    SELECT *
    FROM SDE.VERSIONS
    WHERE NAME = 'Version of interest';

Şimdi ilgi devletin kimliği var. Şimdi, özellik sınıfı için A ve D tablolarını bulmanız gerekiyor. Bunu table_registry dosyasını sorgulayarak yapabilirsiniz. Değer, record_id olacaktır. A ve D tablolarını almak için, record_id'i A ve D'ye eklemeniz yeterli.

    REGISTRATION_ID = 1
    A table would be A1
    D table would be D1

Sonra hem A hem de D tablosunu sorgulayın ve yukarıdaki sorgudan state_id olan girdileri silin.

Ebeveyn ve çocuk ilişkileri hakkında daha fazla bilgi edinmek için aşağıdaki tablolardan sorgulamanız yeterli.

    state_lineages
    versions
    states

Bunların hepsinin ilişkileri var ve zıplayan topu takip etmenize yardımcı olmalı.


1

Bir alt sürümden üst sürüme kaydedildikten sonra yapılan düzenlemeleri geri almak mümkün değildir. Bakınız: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

Gönderme işlemi geri alınamaz çünkü şu anda düzenlemediğiniz bir sürüme değişiklikler uyguluyorsunuz.

Uzlaşma sürecinde her sürümde yapılan düzenlemeleri inceleyebilirsiniz - bu, belirli düzenlemeleri reddetme şansınız olur. Uzlaşma süreci burada açıklanmaktadır .


1

Evet, diğerlerinin dediği gibi kısa cevap hayır.

SDE versiyonlaması çok umut verici, ancak iş akışının sadece özelliklerde ileriye dönük bir değişiklik yapması talihsiz.

SDE’de tam özellikli sürüm oluşturma araçları ...

  • İzin verir (özellik düzeyinde) geri alma ve kabul etme / reddetme
  • Geri almalara izin verir
  • Ve önceki devletlerin geri alımlarına izin verirdi (yani stat 3'ten başlayarak, durum 1'deki değişiklikleri geri al, ancak değişiklikleri durum 2'den koru).

Bu onlar SVN kaynak kodu kontrol versiyonlama sistemi gibi olurlar ama mekansal özellikler için.


Merhaba David, evet, sürümlere bakarken aklımdaki buydu. Ne yazık ki, mevcut iş akışı o kadar fazla esneklik sunmuyor, ancak sanırım devam eden bir çalışma ve sonunda ortaya çıkacak.
Sole23

1
Veriler hiçbir zaman sıkıştırılmazsa teoride istediğiniz kadar geri dönebilirsiniz. Sorun, veritabanı birleştirmelerinin gerçekten yavaşlaması ve sistemin yavaşça kullanılamaz duruma düşmesidir. Sorun, linux çekirdeği gibi devasa bir git kaynak deposunun şu anda ~ 175 MB olduğu kaynak kontrol yönetiminden farklıdır. Geo'da, bu çok daha büyük bir problem olurdu. Yine de, gerçekten akıllı insanlar şu anda bu sorunu düşünüyor. Bkz Geogit: blog.opengeo.org/tag/geogit
Ragi Yaser Burhum

0

Basit cevap HAYIR.

Bir halini göndermeye niyeti etmektir işlemek hedef sürümüne bu düzenlemeleri.

Geri alma gerçekleştirilir değil halini göndermeye (ve bu tür terkedilmiş sürümleri silmek iyi bir uygulamadır).

Sürümü düzenlerken, düzenleme uygulaması (örneğin ArcMap) çeşitli düzeylerde 'geri al' sağlayabilir ve kullanıcı bu tür düzenlemeleri düzenlenmekte olan sürüme kaydetmeyi / kaydetmemeyi seçebilir.

Ancak bir hedefe gönderimden sonra (örneğin sde.default) geri almanın tek yolu sde sistem tablolarına hack etmek.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.