Hozzászólások
[quote:d69effbe7f="samson"]Rosszul gondolod.
Csinald, ahogy mondtam, mukodni fog.
Csak gondolj bele: ha a programozo nem tarolna el a large objectek oidjait, akkor nem is tudna elerni oket kesobb. Legalabbis nem tudna, hogy melyik large object mi.
Ezert van egy tabla, ahol az egyik oszlop tipusa oid. Igaz?
pg_restore szepen updateli ebben az oszlopban az oidokat, tehat minden jo lesz.
sajnos integer a mező típusa, amiben tárolta ez a majom :-)
- A hozzászóláshoz be kell jelentkezni
Az baj, de "select into", "drop table", "create table" utasitassorozattal korrigalhatod konnyeden.
(ugye alterrel nem lehet tipust valtoztatni 7.2-ben)
- A hozzászóláshoz be kell jelentkezni
[quote:67e56f497c="samson"]Rosszul gondolod.
Csinald, ahogy mondtam, mukodni fog.
Csak gondolj bele: ha a programozo nem tarolna el a large objectek oidjait, akkor nem is tudna elerni oket kesobb. Legalabbis nem tudna, hogy melyik large object mi.
Ezert van egy tabla, ahol az egyik oszlop tipusa oid. Igaz?
pg_restore szepen updateli ebben az oszlopban az oidokat, tehat minden jo lesz.
Nem eppen meg mindig:) az oid-jat nem tarolahtod el mint sajat azonosito amit mas tablaban lementesz, mint a fenti eset is pledazta, hogy van ilyen aki azt menti el. Sajat sequenciajaval ellatja az adott large-ot es zat oda drotozza be ahova akarja. oid-ot nem, nem is erre van.
- A hozzászóláshoz be kell jelentkezni
??
- A hozzászóláshoz be kell jelentkezni
[quote:5b46c4faa5="samson"]FYI
Ha large objectet hasznalsz, azt csakis az OIDjaval tudod elerni.
Tehat nem biztos, hogy olyan hulye az a programozo...
En vittem mar at large objectes db-t mashova:
pg_dump -Ft --blobs mydb >f
pg_restore -d mydb2 f
Nem kell -o ahhoz, hogy a large objecteket at tudd vinni.
Csak akkor kellene, ha tenylegesen szukseged van az OIDokra(de ez csak ritkan fordul elo).
A restore szepen el fogja rendezni a large objectek OIDjait. Nem lesznek ugyanazok az uj dbben, de ez nem is baj... a megfelelo hivatkozo tabla OID tipusu oszlopat is szepen valtoztatni fogja...
udv
igen, ez eddig nálam is így történt, teljesen mások lettek az oid-k.
ez a "nem annyira hülye" programozó az oid-okat egy saját info táblába rakta, ahol szerepelnek az aktuális oid-jai és azokra select-el. magyarán bedrótozta ezeket saját mezőkbe. ezt kétlem, hogy a pg_restore frissíteni tudná :-) tehát nekem azért kellett volna, hogy megmaradjanak az oid-ok, mert így olyat keres, ami nem létezik :-(
- A hozzászóláshoz be kell jelentkezni
Rosszul gondolod.
Csinald, ahogy mondtam, mukodni fog.
Csak gondolj bele: ha a programozo nem tarolna el a large objectek oidjait, akkor nem is tudna elerni oket kesobb. Legalabbis nem tudna, hogy melyik large object mi.
Ezert van egy tabla, ahol az egyik oszlop tipusa oid. Igaz?
pg_restore szepen updateli ebben az oszlopban az oidokat, tehat minden jo lesz.
- A hozzászóláshoz be kell jelentkezni
[quote:014c23669d="zedorg"]
Nem eppen meg mindig:) az oid-jat nem tarolahtod el mint sajat azonosito amit mas tablaban lementesz, mint a fenti eset is pledazta, hogy van ilyen aki azt menti el. Sajat sequenciajaval ellatja az adott large-ot es zat oda drotozza be ahova akarja. oid-ot nem, nem is erre van.
A helyzet az, hogy a ki-, majd visszadumpolt adatbazis az redben van minden adat megvan, csak ugye a large objectek oid-je lesz mas. a programozo, aki az oldalt csinalta ezeket az oidokat egy olyan a postgrestol fuggetlen mezoben tarolta, asszem info a neve, tipusa pedig integer, ahonnan hivatkozik rajuk. (a fuggetlenseget arra ertettem, hogy nem oid tipusu...)
amikor a portalt atviszem a masik gepre az adatbazist megtalalja, csak sok hiba van az oldalban, mert nem talalja a bedrotozott oid-os objecteket.
eleg sok reven nem fogok kezzel nekiallni atirogatni mert arra egy elet is keves lenne. azert lett volna jo, ha tokeletesen at lehetne hozni az adatbazist oid-okkal egyutt. mivel egy teljesen uj es szuz adatbazisba kerulnek igy azt gondoltam, hogy van erre mod, hiszen nincsen benne semmi, amivel utkozhetne.
- A hozzászóláshoz be kell jelentkezni
[quote:a6c6e4675d="soky"]Nézd meg itt:
http://search.postgresql.org/www.search?cs=utf-8&ul=http%3A%2F%2Fwww.postgresql.org%2Fdocs%2F8.0%2Finteractive%2F%25&fm=on&gr=on&o=0&ps=20&s=rate&q=restore+oid&submit=Search
sajnos továbbra sem találom a problémám megoldását. egy teljesen üres postgresqlb szeretnék bedumpolni úgy egy adatbázist, hogy minden ugyanaz legyen mint ahonnan hozom. beleértve az OID-okat is. pg7.2-->pg8.0
miért nem sikerül?
- A hozzászóláshoz be kell jelentkezni
nezd meg, hogy a dumpodba ott vannak-e a create table vegein a with oids; Ha nincs, nezd meg 8-as configodat, hogy amit irtak is mar, default_with_oids vagy mi mar, az true-e. Ha minden megvan, akkor az oid-ok ott kell legyenek.
Es a "programozot" pedig ki kell rugni.
- A hozzászóláshoz be kell jelentkezni
FYI
Ha large objectet hasznalsz, azt csakis az OIDjaval tudod elerni.
Tehat nem biztos, hogy olyan hulye az a programozo...
En vittem mar at large objectes db-t mashova:
pg_dump -Ft --blobs mydb >f
pg_restore -d mydb2 f
Nem kell -o ahhoz, hogy a large objecteket at tudd vinni.
Csak akkor kellene, ha tenylegesen szukseged van az OIDokra(de ez csak ritkan fordul elo).
A restore szepen el fogja rendezni a large objectek OIDjait. Nem lesznek ugyanazok az uj dbben, de ez nem is baj... a megfelelo hivatkozo tabla OID tipusu oszlopat is szepen valtoztatni fogja...
udv
- A hozzászóláshoz be kell jelentkezni
[quote:7adeacdb6b="zedorg"]nezd meg, hogy a dumpodba ott vannak-e a create table vegein a with oids; Ha nincs, nezd meg 8-as configodat, hogy amit irtak is mar, default_with_oids vagy mi mar, az true-e. Ha minden megvan, akkor az oid-ok ott kell legyenek.
Es a "programozot" pedig ki kell rugni.
A dumpot --oids szal készítettem, a tar állományon belül a blobs.toc tartalmazza az original oid-okat, de máshol nem találok rá utalást. A CREATE TABLE sor nem tartalmaz OID-szokat, előtte kommentezve vannak csak ilyenek. A 8.0-ás configjában a default_with_oids true -ra van állítva.. és mégis tök mások lesznek az oid-szok.
- A hozzászóláshoz be kell jelentkezni
próbálok egy adatbázist postgre 7.2 -ről átvinni 8.0 -ra
vannak benne large objectek. a gondom az, hogy az object id-k teljesen megváltoznak, hogyan lehet azt is átvinni.
kipróbáltam a:
pg_dump -Ft -o -b adatbázis -f adatbázis.tar
pg_restore -Ft -d adatbázis adatbázis.tar
parancs párost, ami mindent szépen átvisz, kivéve az object id-ket és tök mások lesznek mint az eredetiben, pedig mintha a -o pont arra vonatkozna ahogy kibogarásztam, hogy azokat is vigye. nem?
- A hozzászóláshoz be kell jelentkezni
Az miért baj?
Használod linkelésre az oid-ot?
- A hozzászóláshoz be kell jelentkezni
[quote:e8f2aafc8e="soky"]Az miért baj?
Használod linkelésre az oid-ot?
azt elfelejtettem írni, hogy a balfék programozó bedrótozottan hivatkozik az objectekre, id alapján. ezért kellene az, hogy az objectek id-je azonos maradjon az eredetivel. megoldható ez?
a furcsa az, hogy a tar-ban benne van ezen infó. minek rakja bele, ha nem használja?
- A hozzászóláshoz be kell jelentkezni
Az gáz.
Ha dumpba ki lehet rakni vajon miért nem lehet restore-nak mondani, hogy használja. Talán azért, mert az oid az nem csak az adatbázisra nézve egyedi, hanem az adott installációra. Tehát ha akarná sem tudná azzal visszatölteni, lehet hogy másik adatbázisban már foglalt az az oid.
Programozóval nem lehet egyezkedni, hogy térjen át más modszerre?
Gondolok itt egy sequence generátorral előállított saját azonosítóra.
Másrészt nézegesd a doksit, pl ilyet találtam hirtelen (de nincs több időm kutatni most)
default_with_oids (boolean)
This controls whether CREATE TABLE and CREATE TABLE AS include an OID column in newly-created tables, if neither WITH OIDS nor WITHOUT OIDS is specified. It also determines whether OIDs will be included in tables created by SELECT INTO. In PostgreSQL 8.0.3 default_with_oids defaults to true. This is also the behavior of previous versions of PostgreSQL. However, assuming that tables will contain OIDs by default is not encouraged. This option will probably default to false in a future release of PostgreSQL.
To ease compatibility with applications that make use of OIDs, this option should left enabled. To ease compatibility with future versions of PostgreSQL, this option should be disabled, and applications that require OIDs on certain tables should explicitly specify WITH OIDS when those tables are created.
- A hozzászóláshoz be kell jelentkezni
[quote:118b969fd0="nzmark"] egy olyan a postgrestol fuggetlen mezoben tarolta, asszem info a neve, tipusa pedig integer, ahonnan hivatkozik rajuk. (a fuggetlenseget arra ertettem, hogy nem oid tipusu...)
Kettovel ezelotti hozzaszolasomban leirtam, hogyan lehet megvaltoztatni introl oidra az oszlop tipusat, mi a baj vele?
- A hozzászóláshoz be kell jelentkezni