AppSearchSchema.Builder.AddParentType(String) Méthode

[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

Paramètres

Retours

Attributs

RegisterAttribute

Remarques

Ajoute un type parent au type de schéma pour le polymorphisme, afin que le type de schéma soit considéré comme un sous-type de parentSchemaType. Les relations de sous-type sont automatiquement considérées comme transitives. Les appelants sont donc uniquement tenus de fournir des parents directs. Plus précisément, si T1 <: T2 et T2 <: T3 sont connus, alors T1 <: T3 sera déduit automatiquement, où <: est le symbole de sous-type. Polymorphisme est actuellement pris en charge de la manière suivante : les filtres de recherche sur un type parent sont automatiquement étendus aux types enfants. Par exemple, si Artist <: Person, une recherche avec un filtre sur type Person (en appelant SearchSpec.Builder.addFilterSchemas) inclut également des documents de type Artist dans le résultat de la recherche. Dans l’API de projection, les chemins de propriétés à projet spécifiés pour un type parent sont automatiquement étendus aux types enfants. Si un type parent et un de son type enfant sont spécifiés dans l’API de projection, les chemins du type parent sont fusionnés dans les chemins d’accès de l’enfant. Pour plus d’informations sur la projection, consultez SearchSpec.Builder.addProjection. Une propriété de document définie comme type U est autorisée à être définie avec un document de type T, tant que T <: U, mais notez que l’index sera uniquement basé sur le type défini, qui est U. Par exemple, considérez un document de type « Société » avec un champ « employés » répété de type « Personne ». Nous pouvons ajouter des employés de type « Person » ou « Artist » ou les deux à cette propriété, tant que « Artist » est un sous-type de « Person ». Toutefois, l’index de la propriété « employees » est basé sur ce qui est défini dans « Person », même pour un document ajouté de type « Artist ». Les sous-types doivent répondre aux exigences suivantes. Une violation des exigences entraîne la levée d’une exception AppSearchSession.setSchema avec le code de résultat de AppSearchResult.RESULT_INVALID_ARGUMENT. Considérez un type Artist et un type Person, et Artist prétend être un sous-type de Personne, puis : Chaque propriété en Personne doit avoir une propriété correspondante dans l’Artiste portant le même nom. Chaque propriété non document dans Person doit avoir le même type que le type de la propriété correspondante dans Artist. Par exemple, si « age » est une propriété entière dans Person, alors « age » doit également être une propriété entière dans Artist, au lieu d’une chaîne. Le type de schéma de chaque propriété de document dans Artist doit être un sous-type du type de schéma de la propriété de document correspondante dans Person, si une telle propriété existe dans Person. Par exemple, si « awards » est une propriété de document de type Award in Person, alors le type de la propriété « awards » dans l’artiste doit être un sous-type de prix, par exemple ArtAward. Notez que chaque type est un sous-type de lui-même. Chaque propriété de l’artiste doit avoir une cardinalité plus stricte que ou égale à la cardinalité de la propriété correspondante dans Person, si une telle propriété existe dans Person. Par exemple, si « awards » est une propriété en Personne de cardinalité OPTIONAL, la cardinalité de la propriété « awards » dans l’Artiste ne peut être obligatoire ou FACULTATIVE que. Règle : OBLIGATOIRE < FACULTATIF < RÉPÉTÉ. Il n’existe aucune autre application sur les propriétés correspondantes dans Artist, telles que le type d’index, le type de tokenizer, etc. Ces paramètres peuvent être remplacés en toute sécurité. Un type peut être défini pour avoir plusieurs parents, mais il doit être compatible avec chacun de ses parents en fonction des règles ci-dessus. Par exemple, si LocalBusiness est défini comme un sous-type de place et d’organisation, la compatibilité de LocalBusiness avec Place et la compatibilité de LocalBusiness avec l’organisation est vérifiée.

Référence Android pour android.app.appsearch.AppSearchSchema.Builder.addParentType.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.