আমি কীভাবে একটি জ্যাঙ্গো অ্যাপ্লিকেশন থেকে কোনও নতুন মডেলটিতে স্থানান্তর করব?


126

আমি এতে চারটি মডেল সহ একটি জাঙ্গো অ্যাপ্লিকেশন পেয়েছি। আমি এখন বুঝতে পারি যে এই মডেলগুলির একটির একটি পৃথক অ্যাপে থাকা উচিত। আমি মাইগ্রেশনগুলির জন্য দক্ষিণে ইনস্টলড করেছি, তবে আমি মনে করি না এটি এটি এমন কিছু যা এটি স্বয়ংক্রিয়ভাবে পরিচালনা করতে পারে। কীভাবে আমি পুরানো অ্যাপ্লিকেশনটির মধ্যে একটি মডেলকে নতুন একটিতে স্থানান্তর করতে পারি?

এছাড়াও, মনে রাখবেন যে এটির পুনরাবৃত্তিযোগ্য প্রক্রিয়া হওয়ার জন্য আমি এটির প্রয়োজন যাচ্ছি, যাতে আমি উত্পাদন সিস্টেম এবং এ জাতীয় পরিবর্তন করতে পারি।


6
জ্যাঙ্গো 1.7 এবং উপরোক্ত দেখুন stackoverflow.com/questions/25648393/...
রিক Westera

উত্তর:


184

কীভাবে দক্ষিণ ব্যবহার করে মাইগ্রেশন করবেন।

বলুন যে আমরা দুটি অ্যাপ পেয়েছি: সাধারণ এবং নির্দিষ্ট:

myproject/
|-- common
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   `-- 0002_create_cat.py
|   `-- models.py
`-- specific
    |-- migrations
    |   |-- 0001_initial.py
    |   `-- 0002_create_dog.py
    `-- models.py

এখন আমরা মডেল কমন.মোডেলস.ক্যাটকে নির্দিষ্ট অ্যাপে (সুনির্দিষ্ট নির্দিষ্ট.মোডেলস.ক্যাট) তে সরাতে চাই। প্রথমে সোর্স কোডে পরিবর্তন করুন এবং তারপরে চালান:

$ python manage.py schemamigration specific create_cat --auto
 + Added model 'specific.cat'
$ python manage.py schemamigration common drop_cat --auto
 - Deleted model 'common.cat'

myproject/
|-- common
|   |-- migrations
|   |   |-- 0001_initial.py
|   |   |-- 0002_create_cat.py
|   |   `-- 0003_drop_cat.py
|   `-- models.py
`-- specific
    |-- migrations
    |   |-- 0001_initial.py
    |   |-- 0002_create_dog.py
    |   `-- 0003_create_cat.py
    `-- models.py

এখন আমাদের উভয় স্থানান্তর ফাইল সম্পাদনা করতে হবে:

#0003_create_cat: replace existing forward and backward code
#to use just one sentence:

def forwards(self, orm):
    db.rename_table('common_cat', 'specific_cat') 

    if not db.dry_run:
        # For permissions to work properly after migrating
        orm['contenttypes.contenttype'].objects.filter(
            app_label='common',
            model='cat',
        ).update(app_label='specific')

def backwards(self, orm):
    db.rename_table('specific_cat', 'common_cat')

    if not db.dry_run:
        # For permissions to work properly after migrating
        orm['contenttypes.contenttype'].objects.filter(
            app_label='specific',
            model='cat',
        ).update(app_label='common')

#0003_drop_cat:replace existing forward and backward code
#to use just one sentence; add dependency:

depends_on = (
    ('specific', '0003_create_cat'),
)
def forwards(self, orm):
    pass
def backwards(self, orm):
    pass

এখন উভয় অ্যাপ্লিকেশন মাইগ্রেশন পরিবর্তনের বিষয়ে সচেতন এবং জীবন কিছুটা কম ব্যয় করে :-) অভিবাসনের মধ্যে এই সম্পর্ক নির্ধারণ করা সাফল্যের মূল চাবিকাঠি। এখন আপনি যদি:

python manage.py migrate common
 > specific: 0003_create_cat
 > common: 0003_drop_cat

উভয় স্থানান্তর করতে হবে, এবং

python manage.py migrate specific 0002_create_dog
 < common: 0003_drop_cat
 < specific: 0003_create_cat

জিনিসগুলি নীচে স্থানান্তরিত করবে।

লক্ষ্য করুন যে স্কিমা আপগ্রেড করার জন্য আমি সাধারণ অ্যাপ্লিকেশন ব্যবহার করেছি এবং ডাউনগ্রেডিংয়ের জন্য, আমি নির্দিষ্ট অ্যাপ্লিকেশন ব্যবহার করেছি। কারণ এখানে নির্ভরতা কীভাবে কাজ করে।


1
ওহ ধন্যবাদ. এই প্রশ্নটি জিজ্ঞাসা করার পরে আমি নিজেই দক্ষিণে শিখেছি, তবে আমি নিশ্চিত যে এটি অন্যকে ব্যাপকভাবে সহায়তা করবে।
এপ্রিচ

11
Django_content_type সারণীতে আপনাকে ডেটা স্থানান্তর করতেও পারে।
spookylukey

1
সত্যই দুর্দান্ত গাইড @ পটার। আমি কৌতূহলী, orm['contenttypes.contenttype'].objects.filter এর পিছনের অংশেও কি একটি লাইন থাকা উচিত নয় 0003_create_cat? এছাড়াও আমি একটি টিপ ভাগ করতে চাই। আপনার যদি সূচকগুলি থাকে তবে সেগুলিও সংশোধন করা দরকার। আমার ক্ষেত্রে এগুলি অনন্য সূচী ছিল, সুতরাং আমার অগ্রিমটি দেখতে তাদের মতো দেখাচ্ছে: db.delete_unique('common_cat', ['col1']) db.rename_table('common_cat', 'specific_cat') db.delete_unique('specific_cat', ['col1'])
ব্র্যাড পিচার

2
অ্যাক্সেস করার জন্য orm['contenttypes.contenttype'], আপনাকে --freeze contenttypesআপনার schemamigrationকমান্ডগুলিতে বিকল্পও যুক্ত করতে হবে ।
গ্যারি

1
আমার ক্ষেত্রে (জাজানো 1.5.7.7 এবং দক্ষিণ ১.০) .. আমাকে python manage.py schemamigration specific create_cat --auto --freeze commonসাধারণ অ্যাপ্লিকেশন থেকে বিড়ালের মডেলটিতে অ্যাক্সেস পেতে টাইপ করতে হয়েছিল।
জিউম

35

উপর গড়ে তুলতে Potr Czachur এর উত্তর , পরিস্থিতি যে ForeignKeys জড়িত আরো জটিল এবং সামান্য ভিন্নভাবে নাড়াচাড়া করতে হবে।

(নিম্নলিখিত উদাহরণে উপর তৈরী করে commonএবং specificবর্তমান উত্তরে উল্লেখ করা অ্যাপ্লিকেশানগুলি)।

# common/models.py

class Cat(models.Model):
    # ...

class Toy(models.Model):
    belongs_to = models.ForeignKey(Cat)
    # ...

তাহলে পরিবর্তন হবে

# common/models.py

from specific.models import Cat

class Toy(models.Model):
    belongs_to = models.ForeignKey(Cat)
    # ...

# specific/models.py

class Cat(models.Model):
    # ...

চলমান

./manage.py schemamigration common --auto
./manage.py schemamigration specific --auto # or --initial

নিম্নলিখিত স্থানান্তরগুলি উত্পন্ন করবে (আমি ইচ্ছাকৃতভাবে জ্যাঙ্গো কন্টেন্টটাইপ পরিবর্তনগুলি উপেক্ষা করছি - কীভাবে এটি পরিচালনা করতে হবে তার জন্য পূর্ববর্তী রেফারেন্স করা উত্তর দেখুন):

# common/migrations/0009_auto__del_cat.py

class Migration(SchemaMigration):
    def forwards(self, orm):
        db.delete_table('common_cat')
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.Cat']))

    def backwards(self, orm):
        db.create_table('common_cat', (
            # ...
        ))
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))

# specific/migrations/0004_auto__add_cat.py

class Migration(SchemaMigration):
    def forwards(self, orm):
        db.create_table('specific_cat', (
            # ...
        ))

    def backwards(self, orm):
        db.delete_table('specific_cat')

আপনি দেখতে পাচ্ছেন, নতুন টেবিলের রেফারেন্স করতে এফকে অবশ্যই পরিবর্তন করতে হবে। আমাদের একটি নির্ভরতা যুক্ত করতে হবে যাতে মাইগ্রেশনগুলি প্রয়োগ করা হবে সেই ক্রমটি আমরা জানি (এবং এটিতে কোনও এফকে যুক্ত করার চেষ্টা করার আগে টেবিলটি উপস্থিত থাকবে) তবে আমাদের পিছনের দিকে ঘুরিয়ে দেওয়ার বিষয়টিও নিশ্চিত করতে হবে কারণ এটি নির্ভরতা বিপরীত দিক প্রয়োগ করে

# common/migrations/0009_auto__del_cat.py

class Migration(SchemaMigration):

    depends_on = (
        ('specific', '0004_auto__add_cat'),
    )

    def forwards(self, orm):
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.Cat']))

    def backwards(self, orm):
        db.rename_table('specific_cat', 'common_cat')
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))

# specific/migrations/0004_auto__add_cat.py

class Migration(SchemaMigration):
    def forwards(self, orm):
        db.rename_table('common_cat', 'specific_cat')

    def backwards(self, orm):
        pass

প্রতি দক্ষিণ ডকুমেন্টেশন , depends_onযে নিশ্চিত করবে 0004_auto__add_catসামনে রানের 0009_auto__del_cat যখন সামনে মাইগ্রেট কিন্তু বিপরীত অর্ডার যখন পিছন মাইগ্রেট । আমরা যদি বাম db.rename_table('specific_cat', 'common_cat')মধ্যে specificরোলব্যাক, commonরোলব্যাক ব্যর্থ যখন ForeignKey মাইগ্রেট করতে কারণ টেবিল রেফারেন্সড টেবিল না উপস্থিত হবে চেষ্টা করবে।

আশা করি বিদ্যমান সমাধানগুলির তুলনায় এটি একটি "বাস্তব বিশ্বের" পরিস্থিতির কাছাকাছি এবং কেউ এটি সহায়ক বলে মনে করবেন। চিয়ার্স!


এই উত্তরের নির্দিষ্ট উত্সগুলি কন্টেন্ট টাইপগুলি আপডেট করার জন্য রেখাগুলি বাদ দেয়, যা পটার সিজাচুরের উত্তরে উপস্থিত রয়েছে। এটি বিভ্রান্তিকর হতে পারে।
শাই বার্গার

@ শাইবার্গার আমি এটিকে বিশেষভাবে সম্বোধন করেছিলাম: "আমি ইচ্ছাকৃতভাবে জাঙ্গো কনটেন্ট টাইপ পরিবর্তনগুলি উপেক্ষা করছি that কীভাবে এটি পরিচালনা করতে হবে তার জন্য পূর্ববর্তী রেফারেন্স করা উত্তর দেখুন।"
ম্যাট ব্রায়ানন

9

মডেলগুলি খুব শক্তভাবে অ্যাপগুলিতে মিলিত হয় না, তাই চলন্ত মোটামুটি সহজ। জাজানো অ্যাপ্লিকেশনটির নামটি ডাটাবেস সারণির নামে ব্যবহার করে, তাই আপনি যদি নিজের অ্যাপ্লিকেশনটি সরিয়ে নিতে চান আপনি হয় এসকিউএল ALTER TABLEস্টেটমেন্টের মাধ্যমে ডাটাবেস টেবিলটির নাম পরিবর্তন করতে পারেন , বা - এমনকি সহজ - কেবলমাত্র আপনার মডেলের ক্লাসে db_tableপ্যারামিটারটিMeta উল্লেখ করতে ব্যবহার করতে পারেন পুরাতন নাম

আপনি যদি এখন পর্যন্ত আপনার কোডের যে কোনও জায়গায় কন্টেন্টটাইপস বা জেনেরিক সম্পর্কগুলি ব্যবহার করেছেন তবে আপনি সম্ভবত app_labelযে মডেলটি চালাচ্ছেন সেই কনটেন্টটাইপের নামটির নামকরণ করতে চাইবেন, যাতে বিদ্যমান সম্পর্কগুলি সংরক্ষণ করা যায়।

অবশ্যই, সংরক্ষণ করার জন্য যদি আপনার কাছে কোনও ডেটা না থাকে, তবে সবচেয়ে সহজ কাজটি হ'ল ডাটাবেস টেবিলগুলি পুরোপুরি ফেলে রেখে ./manage.py syncdbআবার চালানো ।


2
দক্ষিণ মাইগ্রেশন দিয়ে আমি কীভাবে এটি করব?
এপ্রেচে

4

এখানে পটারের দুর্দান্ত সমাধানের আরও একটি সমাধান। নিম্নলিখিত নির্দিষ্ট / 0003_create_cat যোগ করুন

depends_on = (
    ('common', '0002_create_cat'),
)

এই নির্ভরতা সেট না করা থাকলে দক্ষিণ গ্যারান্টি দেয় না যে নির্দিষ্ট / 0003_create_catcommon_cat চলমান সময় সারণীটি উপস্থিত রয়েছে, আপনার দিকে ত্রুটি ছুঁড়েছে ।django.db.utils.OperationalError: no such table: common_cat

নির্ভরশীলতা সুস্পষ্টভাবে সেট করা না থাকলে দক্ষিণে লেসিকোগ্রাফিকাল ক্রমে মাইগ্রেশন পরিচালিত হয় । যেহেতু সমস্ত মাইগ্রেশনগুলি টেবিলের নামকরণের আগে চলে আসার commonআগে আসে তাই পটার দেখানো মূল উদাহরণে এটি সম্ভবত পুনরুত্পাদন করতে পারে না। তবে আপনি যদি নাম পরিবর্তন করেন এবং আপনার কাছে এই সমস্যাটি চলে আসবে।specificcommoncommonapp2specificapp1


এটি পটারের উদাহরণের সাথে আসলে সমস্যা নয়। নতুন নামকরণের জন্য এটি নির্দিষ্ট মাইগ্রেশন এবং নির্দিষ্টটির উপর নির্ভর করতে সাধারণ মাইগ্রেশন ব্যবহার করে। নির্দিষ্ট যদি প্রথমে চালানো হয় তবে আপনি ভাল আছেন। সাধারণ যদি প্রথমে চালানো হয়, নির্ভরতা তার আগে নির্দিষ্ট রান তৈরি করে। এটি বলেছিল যে, আমি এটি করার সময় অর্ডারটি অদলবদল করেছিলাম, সুতরাং নতুন নামকরণটি সাধারণভাবে ঘটেছিল এবং নির্দিষ্টভাবে নির্ভরতা ঘটেছিল এবং তারপরে আপনাকে উপরে বর্ণনার মতো নির্ভরতা পরিবর্তন করতে হবে।
এমিল স্টেনস্ট্রোম

1
আমি তোমার সাথে একমত হতে পারি না আমার দৃষ্টিকোণ থেকে সমাধানটি দৃust় হতে হবে এবং এটি খুশি করার চেষ্টা না করেই কাজ করা উচিত। আপনি নতুন ডিবি থেকে সিঙ্কডিবি / মাইগ্রেট করা শুরু করলে আসল সমাধানটি কাজ করে না work আমার প্রস্তাব এটি স্থির করে। যেভাবেই হোক না কেন, পোর্টের উত্তর আমাকে অনেক সময় বাঁচিয়েছিল, তার কাছে
কুডোস

এটি না করার ফলে পরীক্ষাগুলিও ব্যর্থ হতে পারে (তাদের টেস্টের ডেটাবেস তৈরি করার সময় তারা সর্বদা সম্পূর্ণ দক্ষিণ মাইগ্রেশন চালায় বলে মনে হয়)। আমি এর আগেও এরকম কিছু করেছি।
ইহোরকে

4

আমি বর্তমানে যে প্রক্রিয়াটি স্থির করেছি সেখান থেকে কয়েকবার ফিরে এসেছি এবং এটিকে আনুষ্ঠানিক করার সিদ্ধান্ত নিয়েছি।

এটি মূলত দক্ষিণ ০.৮.৪ ব্যবহার করে পটার সিজাচুরের উত্তর এবং ম্যাট ব্রায়াননের উত্তরে নির্মিত হয়েছিল

পদক্ষেপ 1. সন্তানের বিদেশী মূল সম্পর্কগুলি আবিষ্কার করুন

# Caution: This finds OneToOneField and ForeignKey.
# I don't know if this finds all the ways of specifying ManyToManyField.
# Hopefully Django or South throw errors if you have a situation like that.
>>> Cat._meta.get_all_related_objects()
[<RelatedObject: common:toy related to cat>,
 <RelatedObject: identity:microchip related to cat>]

সুতরাং এই বর্ধিত ক্ষেত্রে আমরা এর সাথে সম্পর্কিত আরও একটি মডেল আবিষ্কার করেছি:

# Inside the "identity" app...
class Microchip(models.Model):

    # In reality we'd probably want a ForeignKey, but to show the OneToOneField
    identifies = models.OneToOneField(Cat)

    ...

পদক্ষেপ 2. মাইগ্রেশন তৈরি করুন

# Create the "new"-ly renamed model
# Yes I'm changing the model name in my refactoring too.
python manage.py schemamigration specific create_kittycat --auto

# Drop the old model
python manage.py schemamigration common drop_cat --auto

# Update downstream apps, so South thinks their ForeignKey(s) are correct.
# Can skip models like Toy if the app is already covered
python manage.py schemamigration identity update_microchip_fk --auto

পদক্ষেপ 3. উত্স নিয়ন্ত্রণ: এখন পর্যন্ত পরিবর্তনগুলি প্রতিশ্রুতিবদ্ধ।

যদি আপনি আপডেট হওয়া অ্যাপ্লিকেশনগুলিতে মাইগ্রেশন লেখার মতো টিম সাথীদের মতো মার্জ সংঘাতের মধ্যে চলে যান তবে এটি আরও পুনরাবৃত্তিযোগ্য প্রক্রিয়া করে।

পদক্ষেপ 4. স্থানান্তরের মধ্যে নির্ভরতা যুক্ত করুন।

মূলত create_kittycatসমস্ত কিছুর বর্তমান অবস্থার উপর নির্ভর করে এবং তারপরে সবকিছু নির্ভর করে create_kittycat

# create_kittycat
class Migration(SchemaMigration):

    depends_on = (
        # Original model location
        ('common', 'the_one_before_drop_cat'),

        # Foreign keys to models not in original location
        ('identity', 'the_one_before_update_microchip_fk'),
    )
    ...


# drop_cat
class Migration(SchemaMigration):

    depends_on = (
        ('specific', 'create_kittycat'),
    )
    ...


# update_microchip_fk
class Migration(SchemaMigration):

    depends_on = (
        ('specific', 'create_kittycat'),
    )
    ...

পদক্ষেপ 5. সারণীটির নাম পরিবর্তনটি আমরা করতে চাই।

# create_kittycat
class Migration(SchemaMigration):

    ...

    # Hopefully for create_kittycat you only need to change the following
    # 4 strings to go forward cleanly... backwards will need a bit more work.
    old_app = 'common'
    old_model = 'cat'
    new_app = 'specific'
    new_model = 'kittycat'

    # You may also wish to update the ContentType.name,
    # personally, I don't know what its for and
    # haven't seen any side effects from skipping it.

    def forwards(self, orm):

        db.rename_table(
            '%s_%s' % (self.old_app, self.old_model),
            '%s_%s' % (self.new_app, self.new_model),
        )

        if not db.dry_run:
            # For permissions, GenericForeignKeys, etc to work properly after migrating.
            orm['contenttypes.contenttype'].objects.filter(
                app_label=self.old_app,
                model=self.old_model,
            ).update(
                app_label=self.new_app,
                model=self.new_model,
            )

        # Going forwards, should be no problem just updating child foreign keys
        # with the --auto in the other new South migrations

    def backwards(self, orm):

        db.rename_table(
            '%s_%s' % (self.new_app, self.new_model),
            '%s_%s' % (self.old_app, self.old_model),
        )

        if not db.dry_run:
            # For permissions, GenericForeignKeys, etc to work properly after migrating.
            orm['contenttypes.contenttype'].objects.filter(
                app_label=self.new_app,
                model=self.new_model,
            ).update(
                app_label=self.old_app,
                model=self.old_model,
            )

        # Going backwards, you probably should copy the ForeignKey
        # db.alter_column() changes from the other new migrations in here
        # so they run in the correct order.
        #
        # Test it! See Step 6 for more details if you need to go backwards.
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['common.Cat']))
        db.alter_column('identity_microchip', 'identifies_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['common.Cat']))


# drop_cat
class Migration(SchemaMigration):

    ...

    def forwards(self, orm):
        # Remove the db.delete_table(), if you don't at Step 7 you'll likely get
        # "django.db.utils.ProgrammingError: table "common_cat" does not exist"

        # Leave existing db.alter_column() statements here
        db.alter_column('common_toy', 'belongs_to_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['specific.KittyCat']))

    def backwards(self, orm):
        # Copy/paste the auto-generated db.alter_column()
        # into the create_kittycat migration if you need backwards to work.
        pass


# update_microchip_fk
class Migration(SchemaMigration):

    ...

    def forwards(self, orm):
        # Leave existing db.alter_column() statements here
        db.alter_column('identity_microchip', 'identifies_id', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['specific.KittyCat']))

    def backwards(self, orm):
        # Copy/paste the auto-generated db.alter_column()
        # into the create_kittycat migration if you need backwards to work.
        pass

পদক্ষেপ Only. কেবলমাত্র যদি আপনার কাজ করতে পিছনের দিকে () প্রয়োজন হয় এবং পিছনের দিকে চালানো কী-এরর পান।

# the_one_before_create_kittycat
class Migration(SchemaMigration):

    # You many also need to add more models to South's FakeORM if you run into
    # more KeyErrors, the trade-off chosen was to make going forward as easy as
    # possible, as that's what you'll probably want to do once in QA and once in
    # production, rather than running the following many times:
    #
    # python manage.py migrate specific <the_one_before_create_kittycat>

    models = {
        ...
        # Copied from 'identity' app, 'update_microchip_fk' migration
        u'identity.microchip': {
            'Meta': {'object_name': 'Microchip'},
            u'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
            'name': ('django.db.models.fields.CharField', [], {'unique': 'True', 'max_length': '80'}),
            'identifies': ('django.db.models.fields.related.OneToOneField', [], {to=orm['specific.KittyCat']})
        },
        ...
    }

পদক্ষেপ it. এটি পরীক্ষা করুন - আমার পক্ষে যা কাজ করে তা আপনার বাস্তব জীবনের পরিস্থিতির জন্য যথেষ্ট নাও হতে পারে :)

python manage.py migrate

# If you need backwards to work
python manage.py migrate specific <the_one_before_create_kittycat>

3

সুতরাং উপরের @ পোত্রের আসল প্রতিক্রিয়াটি ব্যবহার করে দক্ষিণ ০.৮.১ এবং জ্যাঙ্গো ২.২.১ এ আমার পক্ষে কাজ হয়নি। আমি নীচে আমার জন্য কী কাজ করেছে তা এই পোস্টে পোস্ট করছি যে এটি অন্যদের পক্ষে সহায়ক।

from south.db import db
from south.v2 import SchemaMigration
from django.db import models

class Migration(SchemaMigration):

    def forwards(self, orm):
        db.rename_table('common_cat', 'specific_cat') 

        if not db.dry_run:
             db.execute(
                "update django_content_type set app_label = 'specific' where "
                " app_label = 'common' and model = 'cat';")

    def backwards(self, orm):
        db.rename_table('specific_cat', 'common_cat')
            db.execute(
                "update django_content_type set app_label = 'common' where "
                " app_label = 'specific' and model = 'cat';")

1

আমি ড্যানিয়েল রোজম্যান তার উত্তরে প্রস্তাবিত বিষয়গুলির মধ্যে একটির আরও সুস্পষ্ট সংস্করণ দিতে যাচ্ছি ...

আপনি যদি কেবলমাত্র db_tableসেই মডেলটির মেটা বৈশিষ্ট্যটি পরিবর্তন করেন তবে আপনি বিদ্যমান টেবিলের নামটি নির্দেশ করতে সরিয়ে নিয়েছেন (নতুন নামের পরিবর্তে জাজঙ্গো এটি নামিয়ে দেবে যদি আপনি বাদ পড়ে এবং এটি করেন syncdb) তবে জটিল জটিল স্থানান্তর এড়াতে পারবেন। উদাহরণ:

মূল:

# app1/models.py
class MyModel(models.Model):
    ...

সরানোর পরে:

# app2/models.py
class MyModel(models.Model):
    class Meta:
        db_table = "app1_mymodel"

এখন আপনি শুধু আপডেট করার জন্য একটি ডাটা স্থানান্তরণ করতে প্রয়োজন app_labelজন্য MyModeldjango_content_typeটেবিল এবং আপনি ভাল যেতে হওয়া উচিত ...

চালান ./manage.py datamigration django update_content_typeতারপরে দক্ষিণ আপনার জন্য তৈরি করা ফাইলটি সম্পাদনা করুন:

def forwards(self, orm):
    moved = orm.ContentType.objects.get(app_label='app1', model='mymodel')
    moved.app_label = 'app2'
    moved.save()

def backwards(self, orm):
    moved = orm.ContentType.objects.get(app_label='app2', model='mymodel')
    moved.app_label = 'app1'
    moved.save()
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.