Dokumentationen modellreferens förklarar hur man använder Djangos standardfältklasser - CharField, DateField, etc. För många ändamål är dessa klasser allt du behöver. Ibland kommer dock Django-versionen inte att uppfylla dina exakta krav, eller så vill du använda ett fält som är helt annorlunda än de som levereras med Django.
Djangos inbyggda fälttyper täcker inte alla möjliga databaskolonntyper - bara de vanliga typerna, till exempel VARCHAR och INTEGER. För mer obskyra kolumntyper, till exempel geografiska polygoner eller till och med användarskapade typer som PostgreSQL anpassade typer, kan du definiera dina egna Django Field underklasser.
Alternativt kan du ha ett komplext Python-objekt som på något sätt kan serialiseras för att passa in i en standardkolumntyp i databasen. Detta är ett annat fall där en Field subklass kommer att hjälpa dig att använda ditt objekt med dina modeller.
Att skapa anpassade fält kräver lite uppmärksamhet på detaljer. För att göra det lättare att följa kommer vi att använda ett konsekvent exempel genom hela detta dokument: att omsluta ett Python-objekt som representerar korten i en hand i Bridge. Oroa dig inte, du behöver inte kunna spela Bridge för att följa detta exempel. Du behöver bara veta att 52 kort delas ut jämnt mellan fyra spelare, som traditionellt kallas norr, öst, söder och väst. Vår klass ser ungefär så här ut:
\nclass Hand:\n """A hand of cards (bridge style)"""\n\n def __init__(self, north, east, south, west):\n # Input parameters are lists of cards ('Ah', '9s', etc.)\n self.north = north\n self.east = east\n self.south = south\n self.west = west\n\n # ... (other possibly useful methods omitted) ...\nDetta är en vanlig Python-klass, utan något Django-specifikt med den. Vi skulle vilja kunna göra saker som detta i våra modeller (vi antar att hand-attributet på modellen är en instans av Hand):
example = MyModel.objects.get(pk=1)\nprint(example.hand.north)\n\nnew_hand = Hand(north, east, south, west)\nexample.hand = new_hand\nexample.save()\nVi tilldelar och hämtar från hand-attributet i vår modell precis som alla andra Python-klasser. Tricket är att berätta för Django hur man hanterar att spara och ladda ett sådant objekt.
För att kunna använda klassen Hand i våra modeller behöver vi inte ändra den här klassen överhuvudtaget. Detta är idealiskt, eftersom det innebär att du enkelt kan skriva modellstöd för befintliga klasser där du inte kan ändra källkoden.
Låt oss börja med modellfält. Om du bryter ner det, ger ett modellfält ett sätt att ta ett normalt Python-objekt - sträng, boolean, datetime eller något mer komplext som Hand - och konvertera det till och från ett format som är användbart när du hanterar databasen. (Ett sådant format är också användbart för serialisering, men som vi kommer att se senare är det lättare när du har databassidan under kontroll).
Fält i en modell måste på något sätt konverteras så att de passar in i en befintlig kolumntyp i databasen. Olika databaser har olika uppsättningar av giltiga kolumntyper, men regeln är ändå densamma: det är de enda typerna du behöver arbeta med. Allt som du vill lagra i databasen måste passa in i någon av dessa typer.
\nNormalt skriver du antingen ett Django-fält för att matcha en viss kolumntyp i databasen, eller så behöver du ett sätt att konvertera dina data till exempelvis en sträng.
\nI vårt exempel med Hand kan vi konvertera kortdata till en sträng med 104 tecken genom att sammanfoga alla kort i en förutbestämd ordning - t.ex. alla north-kort först, sedan east-, south- och west-kort. Så Hand-objekt kan sparas i text- eller teckenkolumner i databasen.
Alla Djangos fält (och när vi säger fält i detta dokument menar vi alltid modellfält och inte formulärsfält) är underklasser till django.db.models.Field. Det mesta av den information som Django registrerar om ett fält är gemensam för alla fält - namn, hjälptext, unikhet och så vidare. Lagring av all denna information hanteras av Field. Vi kommer att gå in på de exakta detaljerna om vad Field kan göra senare; för nu räcker det att säga att allt härstammar från Field och sedan anpassar viktiga delar av klassens beteende.
Det är viktigt att inse att en Django-fältklass inte är det som lagras i dina modellattribut. Modellattributen innehåller normala Python-objekt. De fältklasser som du definierar i en modell lagras faktiskt i klassen Meta när modellklassen skapas (de exakta detaljerna om hur detta görs är oviktiga här). Detta beror på att fältklasserna inte är nödvändiga när du bara skapar och ändrar attribut. Istället tillhandahåller de maskineriet för att konvertera mellan attributvärdet och det som lagras i databasen eller skickas till serializer.
Tänk på detta när du skapar dina egna anpassade fält. Den Django Field subklass du skriver tillhandahåller maskineriet för att konvertera mellan dina Python-instanser och databas/serializer-värden på olika sätt (det finns skillnader mellan att lagra ett värde och använda ett värde för uppslagningar, till exempel). Om det här låter lite knepigt, oroa dig inte - det kommer att bli tydligare i exemplen nedan. Kom bara ihåg att du ofta kommer att skapa två klasser när du vill ha ett anpassat fält:
Den första klassen är det Python-objekt som dina användare kommer att manipulera. De kommer att tilldela det till model-attributet, de kommer att läsa från det för visningsändamål, saker som det. Detta är klassen Hand i vårt exempel.
Den andra klassen är underklassen Field. Det här är klassen som vet hur man konverterar den första klassen fram och tillbaka mellan dess permanenta lagringsform och Python-form.
När du planerar din Field-underklass, tänk först på vilken befintlig Field-klass ditt nya fält är mest lik. Kan du subklassa ett befintligt Django-fält och spara dig lite arbete? Om inte, bör du subklassa Field-klassen, från vilken allt härstammar.
Initialisering av ditt nya fält är en fråga om att separera alla argument som är specifika för ditt fall från de vanliga argumenten och skicka de senare till metoden __init__() i Field (eller din överordnade klass).
I vårt exempel kommer vi att kalla vårt fält HandField. (Det är en bra idé att kalla din Field subklass för <Something>Field, så att den lätt kan identifieras som en Field subklass) Det beter sig inte som något befintligt fält, så vi kommer att subklassa direkt från Field:
from django.db import models\n\n\nclass HandField(models.Field):\n description = "A hand of cards (bridge style)"\n\n def __init__(self, *args, **kwargs):\n kwargs["max_length"] = 104\n super().__init__(*args, **kwargs)\nVårt HandField accepterar de flesta av standardfältalternativen (se listan nedan), men vi ser till att det har en fast längd, eftersom det bara behöver innehålla 52 kortvärden plus deras färger; totalt 104 tecken.
Metoden Field.__init__() tar emot följande parametrar:
namn
rel: Används för relaterade fält (som ForeignKey). Endast för avancerad användning.
serialize: Om False, kommer fältet inte att serialiseras när modellen skickas till Djangos serializers. Standardvärde är True.
db_tablespace: Endast för skapande av index, om backend stöder tablespaces. Du kan vanligtvis ignorera detta alternativ.
auto_created: True om fältet skapades automatiskt, som för OneToOneField som används av modellarv. Endast för avancerad användning.
Alla alternativ utan förklaring i listan ovan har samma betydelse som de har för vanliga Django-fält. Se fältdokumentation för exempel och detaljer.
\nMotpolen till att skriva din __init__()-metod är att skriva deconstruct()-metoden. Den används under modellmigreringar för att tala om för Django hur man tar en instans av ditt nya fält och reducerar det till en serialiserad form - i synnerhet vilka argument som ska skickas till __init__() för att återskapa det.
Om du inte har lagt till några extra alternativ utöver det fält du ärvde från, behöver du inte skriva en ny metod deconstruct(). Om du däremot ändrar de argument som skickas i __init__() (som vi gör i HandField), måste du komplettera de värden som skickas.
deconstruct() returnerar en tupel med fyra objekt: fältets attributnamn, fältklassens fullständiga importsökväg, de positionella argumenten (som en lista) och nyckelordsargumenten (som en dict). Observera att detta skiljer sig från metoden deconstruct() for custom classes som returnerar en tupel av tre saker.
Som författare till ett anpassat fält behöver du inte bry dig om de två första värdena; basklassen Field har all kod för att räkna ut fältets attributnamn och importsökväg. Du måste dock bry dig om positions- och nyckelordsargumenten, eftersom det sannolikt är dessa saker du ändrar.
Till exempel, i vår HandField-klass ställer vi alltid in max_length i __init__(). Metoden deconstruct() på basklassen Field kommer att se detta och försöka returnera det i nyckelordsargumenten; därför kan vi ta bort det från nyckelordsargumenten för läsbarhetens skull:
from django.db import models\n\n\nclass HandField(models.Field):\n def __init__(self, *args, **kwargs):\n kwargs["max_length"] = 104\n super().__init__(*args, **kwargs)\n\n def deconstruct(self):\n name, path, args, kwargs = super().deconstruct()\n del kwargs["max_length"]\n return name, path, args, kwargs\nOm du lägger till ett nytt nyckelordsargument måste du själv skriva kod i deconstruct() som lägger in dess värde i kwargs. Du bör också utelämna värdet från kwargs när det inte är nödvändigt att rekonstruera fältets tillstånd, till exempel när standardvärdet används:
from django.db import models\n\n\nclass CommaSepField(models.Field):\n "Implements comma-separated storage of lists"\n\n def __init__(self, separator=",", *args, **kwargs):\n self.separator = separator\n super().__init__(*args, **kwargs)\n\n def deconstruct(self):\n name, path, args, kwargs = super().deconstruct()\n # Only include kwarg if it's not the default\n if self.separator != ",":\n kwargs["separator"] = self.separator\n return name, path, args, kwargs\nMer komplexa exempel ligger utanför ramen för detta dokument, men kom ihåg - för varje konfiguration av din Field-instans måste deconstruct() returnera argument som du kan skicka till __init__ för att rekonstruera det tillståndet.
Var extra uppmärksam om du anger nya standardvärden för argument i superklassen Field; du vill vara säker på att de alltid inkluderas, snarare än att försvinna om de får det gamla standardvärdet.
Dessutom bör du försöka undvika att returnera värden som positionella argument; när det är möjligt, returnera värden som nyckelordsargument för maximal framtida kompatibilitet. Om du ändrar namn på saker oftare än deras position i konstruktörens argumentlista kanske du föredrar positionella, men kom ihåg att människor kommer att rekonstruera ditt fält från den serialiserade versionen under ett bra tag (kanske år), beroende på hur länge dina migreringar pågår.
\nDu kan se resultatet av dekonstruktionen genom att titta i migreringar som innehåller fältet, och du kan testa dekonstruktionen i enhetstester genom att dekonstruera och rekonstruera fältet:
\nname, path, args, kwargs = my_field_instance.deconstruct()\nnew_instance = MyField(*args, **kwargs)\nself.assertEqual(my_field_instance.some_attribute, new_instance.some_attribute)\nDu kan åsidosätta Field.non_db_attrs för att anpassa attribut för ett fält som inte påverkar en kolumndefinition. Det används under modellmigreringar för att upptäcka no-op AlterField-operationer.
Till exempel:
\nclass CommaSepField(models.Field):\n @property\n def non_db_attrs(self):\n return super().non_db_attrs + ("separator",)\nDu kan inte ändra basklassen för ett anpassat fält eftersom Django inte kommer att upptäcka ändringen och göra en migrering för den. Till exempel, om du börjar med:
\nclass CustomCharField(models.CharField): ...\noch sedan bestämmer dig för att du vill använda TextField istället, kan du inte ändra underklassen så här:
class CustomCharField(models.TextField): ...\nIstället måste du skapa en ny klass för anpassade fält och uppdatera dina modeller så att de refererar till den:
\nclass CustomCharField(models.CharField): ...\n\n\nclass CustomTextField(models.TextField): ...\nSom diskuterades i Ta bort fält måste du behålla den ursprungliga klassen CustomCharField så länge du har migreringar som refererar till den.
Som alltid bör du dokumentera din fälttyp så att användarna vet vad det är. Förutom att tillhandahålla en docstring för den, vilket är användbart för utvecklare, kan du också låta användare av admin-appen se en kort beskrivning av fälttypen via django.contrib.admindocs-applikationen. För att göra detta tillhandahåller du beskrivande text i ett description klassattribut för ditt anpassade fält. I exemplet ovan kommer den beskrivning som visas av applikationen admindocs för ett HandField att vara ”En hand med kort (bridgestil)”.
I visningen django.contrib.admindocs interpoleras fältbeskrivningen med field.__dict__ vilket gör att beskrivningen kan innehålla fältets argument. Till exempel är beskrivningen för CharField:
description = _("String (up to %(max_length)s)")\nNär du har skapat din Field-underklass kan du överväga att åsidosätta några standardmetoder, beroende på ditt fälts beteende. Listan över metoder nedan är i ungefärlig fallande ordning efter betydelse, så börja från toppen.
Säg att du har skapat en PostgreSQL anpassad typ som heter mytype. Du kan underklassa Field och implementera db_type() -metoden, så här:
from django.db import models\n\n\nclass MytypeField(models.Field):\n def db_type(self, connection):\n return "mytype"\nNär du har MytypeField kan du använda den i vilken modell som helst, precis som vilken annan Field-typ som helst:
class Person(models.Model):\n name = models.CharField(max_length=80)\n something_else = MytypeField()\nOm du strävar efter att bygga en databasagnostisk applikation bör du ta hänsyn till skillnader i databaskolonntyper. Till exempel kallas kolumntypen datum / tid i PostgreSQL timestamp, medan samma kolumn i MySQL kallas datetime. Du kan hantera detta i en db_type()-metod genom att kontrollera attributet connection.vendor. Nuvarande inbyggda leverantörsnamn är: sqlite, postgresql, mysql och oracle.
Till exempel:
\nclass MyDateField(models.Field):\n def db_type(self, connection):\n if connection.vendor == "mysql":\n return "datetime"\n else:\n return "timestamp"\nMetoderna db_type() och rel_db_type() anropas av Django när ramverket konstruerar CREATE TABLE-satserna för din applikation - det vill säga när du först skapar dina tabeller. Metoderna anropas också när du konstruerar en WHERE-sats som innehåller modellfältet - det vill säga när du hämtar data med QuerySet-metoder som get(), filter() och exclude() och har modellfältet som ett argument.
Vissa databaskolumntyper accepterar parametrar, till exempel CHAR(25), där parametern 25 representerar den maximala kolumnlängden. I sådana fall är det mer flexibelt om parametern anges i modellen istället för att vara hårdkodad i metoden db_type(). Det skulle till exempel inte vara särskilt meningsfullt att ha ett CharMaxlength25Field, som visas här:
# This is a silly example of hardcoded parameters.\nclass CharMaxlength25Field(models.Field):\n def db_type(self, connection):\n return "char(25)"\n\n\n# In the model:\nclass MyModel(models.Model):\n # ...\n my_field = CharMaxlength25Field()\nEtt bättre sätt att göra detta vore att göra parametern specificerbar vid körning, dvs. när klassen instansieras. För att göra det, implementera Field.__init__(), så här:
# This is a much more flexible example.\nclass BetterCharField(models.Field):\n def __init__(self, max_length, *args, **kwargs):\n self.max_length = max_length\n super().__init__(*args, **kwargs)\n\n def db_type(self, connection):\n return "char(%s)" % self.max_length\n\n\n# In the model:\nclass MyModel(models.Model):\n # ...\n my_field = BetterCharField(25)\nSlutligen, om din kolumn kräver en verkligt komplex SQL-konfiguration, returnera None från db_type(). Detta kommer att leda till att Djangos SQL-skapande kod hoppar över detta fält. Du är sedan ansvarig för att skapa kolumnen i rätt tabell på något annat sätt, men det här ger dig ett sätt att berätta för Django att komma ur vägen.
Metoden rel_db_type() anropas av fält som ForeignKey och OneToOneField som pekar på ett annat fält för att bestämma datatyperna för deras databaskolumner. Om du till exempel har ett UnsignedAutoField behöver du också de främmande nycklar som pekar på det fältet för att använda samma datatyp:
# MySQL unsigned integer (range 0 to 4294967295).\nclass UnsignedAutoField(models.AutoField):\n def db_type(self, connection):\n return "integer UNSIGNED AUTO_INCREMENT"\n\n def rel_db_type(self, connection):\n return "integer UNSIGNED"\nOm din anpassade klass Field hanterar datastrukturer som är mer komplexa än strängar, datum, heltal eller flyttal kan du behöva åsidosätta from_db_value() och to_python().
Om det finns för fältunderklassen kommer from_db_value() att anropas under alla omständigheter när data laddas från databasen, inklusive i aggregat och values()-anrop.
to_python() anropas vid deserialisering och under clean()-metoden som används från formulär.
Som en allmän regel bör to_python() hantera något av följande argument på ett elegant sätt:
En instans av rätt typ (t.ex. Hand i vårt pågående exempel).
En sträng
None (om fältet tillåter null=True)
I vår HandField-klass lagrar vi data som ett VARCHAR-fält i databasen, så vi måste kunna bearbeta strängar och None i from_db_value(). I to_python() måste vi också hantera Hand-instanser:
import re\n\nfrom django.core.exceptions import ValidationError\nfrom django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\n\ndef parse_hand(hand_string):\n """Takes a string of cards and splits into a full hand."""\n p1 = re.compile(".{26}")\n p2 = re.compile("..")\n args = [p2.findall(x) for x in p1.findall(hand_string)]\n if len(args) != 4:\n raise ValidationError(_("Invalid input for a Hand instance"))\n return Hand(*args)\n\n\nclass HandField(models.Field):\n # ...\n\n def from_db_value(self, value, expression, connection):\n if value is None:\n return value\n return parse_hand(value)\n\n def to_python(self, value):\n if isinstance(value, Hand):\n return value\n\n if value is None:\n return value\n\n return parse_hand(value)\nLägg märke till att vi alltid returnerar en Hand-instans från dessa metoder. Det är Python-objekttypen som vi vill lagra i modellens attribut.
För to_python(), om något går fel under värdekonvertering, bör du höja ett ValidationError undantag.
Eftersom användning av en databas kräver konvertering i båda riktningarna, om du åsidosätter from_db_value() måste du också åsidosätta get_prep_value() för att konvertera Python-objekt tillbaka till frågevärden.
Till exempel:
\nclass HandField(models.Field):\n # ...\n\n def get_prep_value(self, value):\n return "".join(\n ["".join(l) for l in (value.north, value.east, value.south, value.west)]\n )\nVissa datatyper (t.ex. datum) måste vara i ett visst format innan de kan användas av en databas. get_db_prep_value() är den metod där dessa konverteringar ska göras. Den specifika anslutning som kommer att användas för frågan skickas som parametern connection. Detta gör att du kan använda backend-specifik konverteringslogik om det krävs.
Till exempel använder Django följande metod för sin BinaryField:
def get_db_prep_value(self, value, connection, prepared=False):\n value = super().get_db_prep_value(value, connection, prepared)\n if value is not None:\n return connection.Database.Binary(value)\n return value\nOm ditt anpassade fält behöver en särskild konvertering när det sparas som inte är densamma som den konvertering som används för normala frågeparametrar kan du åsidosätta get_db_prep_save().
Om du vill förbehandla värdet precis innan du sparar det kan du använda pre_save(). Till exempel använder Djangos DateTimeField den här metoden för att ställa in attributet korrekt i fallet med auto_now eller auto_now_add.
Om du åsidosätter den här metoden måste du returnera attributets värde i slutet. Du bör också uppdatera modellens attribut om du gör några ändringar i värdet så att kod som har referenser till modellen alltid ser rätt värde.
\nFör att anpassa det formulärfält som används av ModelForm kan du åsidosätta formfield().
Klassen för formulärfältet kan specificeras via argumenten form_class och choices_form_class; det senare används om fältet har specificerade val, det förra annars. Om dessa argument inte anges kommer CharField eller TypedChoiceField att användas.
Hela kwargs-ordlistan skickas direkt till formulärfältets __init__()-metod. Normalt behöver du bara skapa en bra standard för argumentet form_class (och kanske choices_form_class) och sedan delegera vidare hantering till överordnad klass. Detta kan kräva att du skriver ett anpassat formulärfält (och till och med en formulärwidget). Se formulärdokumentation för information om detta.
Om du vill utesluta fältet från ModelForm kan du åsidosätta metoden formfield() så att den returnerar None.
Fortsätter vi med vårt pågående exempel kan vi skriva formfield()-metoden som:
class HandField(models.Field):\n # ...\n\n def formfield(self, **kwargs):\n # Exclude the field from the ModelForm when some condition is met.\n some_condition = kwargs.get("some_condition", False)\n if some_condition:\n return None\n\n # Set up some defaults while letting the caller override them.\n defaults = {"form_class": MyFormField}\n defaults.update(kwargs)\n return super().formfield(**defaults)\nDetta förutsätter att vi har importerat fältklassen MyFormField (som har sin egen standardwidget). Detta dokument täcker inte detaljerna i att skriva anpassade formulärfält.
Om du har skapat en db_type()-metod behöver du inte oroa dig för get_internal_type() - den kommer inte att användas särskilt mycket. Ibland är dock databaslagringen av samma typ som något annat fält, och då kan du använda det andra fältets logik för att skapa rätt kolumn.
Till exempel:
\nclass HandField(models.Field):\n # ...\n\n def get_internal_type(self):\n return "CharField"\nOavsett vilken databasbackend vi använder kommer detta att innebära att migrate och andra SQL-kommandon skapar rätt kolumntyp för lagring av en sträng.
Om get_internal_type() returnerar en sträng som inte är känd för Django för den databasbackend du använder - det vill säga, den visas inte i django.db.backends.<db_name>.base.DatabaseWrapper.data_types - kommer strängen fortfarande att användas av serialiseraren, men standardmetoden db_type() kommer att returnera None. Se dokumentationen av db_type() för skäl till varför detta kan vara användbart. Att lägga in en beskrivande sträng som typ av fält för serializer är en bra idé om du någonsin kommer att använda serializer-utdata på någon annan plats utanför Django.
Om du vill anpassa hur värdena serialiseras av en serializer kan du åsidosätta value_to_string(). Att använda value_from_object() är det bästa sättet att få fältets värde före serialisering. Till exempel, eftersom HandField ändå använder strängar för sin datalagring, kan vi återanvända en del befintlig konverteringskod:
class HandField(models.Field):\n # ...\n\n def value_to_string(self, obj):\n value = self.value_from_object(obj)\n return self.get_prep_value(value)\nAtt skriva ett anpassat fält kan vara en knepig process, särskilt om du gör komplexa konverteringar mellan dina Python-typer och dina databas- och serialiseringsformat. Här är ett par tips för att få saker och ting att gå smidigare:
\nTitta på de befintliga Django-fälten (i django/db/models/fields/__init__.py) för inspiration. Försök att hitta ett fält som liknar det du vill ha och utöka det lite, istället för att skapa ett helt nytt fält från grunden.
Lägg till en __str__()-metod på den klass som du paketerar som ett fält. Det finns många ställen där standardbeteendet för fältkoden är att anropa str() på värdet. (I våra exempel i detta dokument skulle värde vara en Hand-instans, inte en HandField). Så om din __str__()-metod automatiskt konverterar till strängformen av ditt Python-objekt kan du spara dig mycket arbete.
FileFieldLink to this heading#Förutom ovanstående metoder har fält som hanterar filer några andra speciella krav som måste tas i beaktande. Majoriteten av den mekanik som tillhandahålls av FileField, t.ex. styrning av databaslagring och hämtning, kan förbli oförändrad, vilket gör att underklasser kan hantera utmaningen att stödja en viss typ av fil.
Django tillhandahåller en File-klass, som används som en proxy för filens innehåll och operationer. Detta kan underklassificeras för att anpassa hur filen nås och vilka metoder som är tillgängliga. Den lever på django.db.models.fields.files, och dess standardbeteende förklaras i fil dokumentation.
När en subklass av File har skapats måste den nya subklassen FileField få veta att den ska använda den. Detta görs genom att tilldela den nya subklassen File det speciella attributet attr_class för subklassen FileField.
Utöver ovanstående detaljer finns det några riktlinjer som avsevärt kan förbättra effektiviteten och läsbarheten i fältets kod.
\nKällan till Djangos egen ImageField (i django/db/models/fields/files.py) är ett bra exempel på hur man kan underklassa FileField för att stödja en viss typ av fil, eftersom den innehåller alla de tekniker som beskrivs ovan.
Cacha filattribut när det är möjligt. Eftersom filer kan lagras i fjärrlagringssystem kan det kosta extra tid, eller till och med pengar, att hämta dem, vilket inte alltid är nödvändigt. När en fil har hämtats för att få information om dess innehåll bör så mycket som möjligt av informationen cachas för att minska antalet gånger som filen måste hämtas vid senare anrop för att få samma information.