AppSearchSchema.Builder.AddParentType(String) Methode

[Android.Runtime.Register("addParentType", "(Ljava/lang/String;)Landroid/app/appsearch/AppSearchSchema$Builder;", "", ApiSince=35)]
public Android.App.AppSearch.AppSearchSchema.Builder AddParentType(string parentSchemaType);

[<Android.Runtime.Register("addParentType", "(Ljava/lang/String;)Landroid/app/appsearch/AppSearchSchema$Builder;", "", ApiSince=35)>]
member this.AddParentType : string -> Android.App.AppSearch.AppSearchSchema.Builder

Parameter

Gibt zurück

Attribute

RegisterAttribute

Hinweise

Fügt dem Schematyp für Polymorphismus einen übergeordneten Typ hinzu, sodass der Schematyp als Untertyp von parentSchemaType betrachtet wird. Subtypbeziehungen werden automatisch als transitiv betrachtet, daher müssen Anrufer nur direkte Eltern bereitstellen. Wenn T1 <: T2 und T2 <: T3 bekannt sind, wird T1 <: T3 automatisch abgeleitet, wobei <: ist das Untertypsymbol. Polymorphismus wird derzeit auf folgende Weise unterstützt: Suchfilter für einen übergeordneten Typ werden automatisch auch auf die untergeordneten Typen erweitert. Wenn z. B. Artist <: Person, dann eine Suche mit einem Filter nach Typ Person (durch Aufrufen von SearchSpec.Builder.addFilterSchemas ) auch Dokumente vom Typ "Artist" in das Suchergebnis einschließen. In der Projektions-API werden die für einen übergeordneten Typ angegebenen Eigenschaftspfade automatisch auch auf die untergeordneten Typen erweitert. Wenn sowohl ein übergeordneter Typ als auch ein untergeordneter Typ in der Projektions-API angegeben sind, werden die Pfade des übergeordneten Typs mit den untergeordneten Elementen zusammengeführt. Weitere Informationen zur Projektion finden Sie unter SearchSpec.Builder.addProjection. Eine dokumenteigenschaft, die als Typ U definiert ist, darf mit einem Dokument vom Typ T festgelegt werden, solange T <: U, aber beachten Sie, dass index nur auf dem definierten Typ basiert, der U ist. Betrachten Sie z. B. ein Dokument vom Typ "Firma" mit einem wiederholten Feld "Mitarbeiter" vom Typ "Person". Wir können Mitarbeiter vom Typ "Person" oder "Künstler" oder beides zu dieser Eigenschaft hinzufügen, solange "Artist" ein Untertyp von "Person" ist. Der Index der Eigenschaft "employees" basiert jedoch auf dem, was in "Person" definiert ist, auch für ein hinzugefügtes Dokument vom Typ "Künstler". Untertypen müssen die folgenden Anforderungen erfüllen. Ein Verstoß gegen die Anforderungen führt dazu, dass AppSearchSession.setSchema eine AppSearchException mit dem Ergebniscode von AppSearchResult.RESULT_INVALID_ARGUMENT auslöst. Betrachten Sie einen Typ "Künstler" und einen Typ "Person", und "Künstler" als Untertyp "Person", dann: Jede Eigenschaft in Person muss über eine entsprechende Eigenschaft in Artist mit demselben Namen verfügen. Jede Nicht-Dokumenteigenschaft in Person muss denselben Typ wie der Typ der entsprechenden Eigenschaft in Artist aufweisen. Wenn "age" z. B. eine ganzzahlige Eigenschaft in Person ist, muss "age" auch eine ganzzahlige Eigenschaft in Artist anstelle einer Zeichenfolge sein. Der Schematyp jeder Dokumenteigenschaft in Artist muss ein Untertyp des Schematyps der entsprechenden Dokumenteigenschaft in Person sein, wenn eine solche Eigenschaft in Person vorhanden ist. Wenn "Awards" z. B. eine Dokumenteigenschaft vom Typ "Award in Person" ist, muss der Typ der Eigenschaft "Awards" in Artist ein Untertyp von Award sein, z. B. ArtAward. Beachten Sie, dass jeder Typ ein Untertyp von sich selbst ist. Jede Eigenschaft in Artist muss eine Kardinalität strenger oder gleich der Kardinalität der entsprechenden Eigenschaft in Person haben, wenn eine solche Eigenschaft persönlich vorhanden ist. Wenn "Awards" z. B. eine Eigenschaft in Person von Kardinalität OPTIONAL ist, kann die Kardinalität der Eigenschaft "awards" in Artist nur ERFORDERLICH oder OPTIONAL sein. Regel: ERFORDERLICH OPTIONAL << WIEDERHOLT. Es gibt keine weiteren Erzwingungen für die entsprechenden Eigenschaften in Artist, z. B. Indextyp, Tokenizertyp usw. Diese Einstellungen können sicher außer Kraft gesetzt werden. Ein Typ kann definiert werden, um mehrere Eltern zu haben, muss aber mit jedem seiner Eltern kompatibel sein, basierend auf den oben genannten Regeln. Wenn "LocalBusiness" beispielsweise als Untertyp von "Place" und "Organization" definiert ist, wird die Kompatibilität von LocalBusiness mit "Place" und "LocalBusiness with Organization" überprüft.

Android-Referenz für android.app.appsearch.AppSearchSchema.Builder.addParentType.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.