AppSearchSchema.Builder.AddParentType(String) Método

[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

Parámetros

Devoluciones

Atributos

RegisterAttribute

Comentarios

Agrega un tipo primario al tipo de esquema para el polimorfismo, de modo que el tipo de esquema se considerará un subtipo de parentSchemaType. Las relaciones de subtipo se consideran transitivas automáticamente, por lo que los autores de llamada solo son necesarios para proporcionar padres directos. En concreto, si se conocen T1 <: T2 y T2 <: T3, T1 <: T3 se deducirá automáticamente, donde <: es el símbolo de subtipo. El polimorfismo se admite actualmente de las siguientes maneras: los filtros de búsqueda en un tipo primario también se extenderán automáticamente a los tipos secundarios. Por ejemplo, si Artist <: Person, una búsqueda con un filtro en el tipo Person (llamando a SearchSpec.Builder.addFilterSchemas ) también incluirá documentos de tipo Artist en el resultado de búsqueda. En la API de proyección, las rutas de acceso de propiedad al proyecto especificadas para un tipo primario también se extenderán a los tipos secundarios. Si se especifica un tipo primario y uno de su tipo secundario en la API de proyección, las rutas de acceso del tipo primario se combinarán en el elemento secundario. Para obtener más información sobre la proyección, vea SearchSpec.Builder.addProjection. Se permite establecer una propiedad de documento definida como tipo U con un documento de tipo T, siempre que T : U <, pero tenga en cuenta que el índice solo se basará en el tipo definido, que es U. Por ejemplo, considere un documento de tipo "Empresa" con un campo "empleados" repetido de tipo "Persona". Podemos agregar empleados de tipo "Person" o "Artist" o ambos a esta propiedad, siempre y cuando "Artist" sea un subtipo de "Person". Sin embargo, el índice de la propiedad "employees" se basará en lo que se define en "Person", incluso para un documento agregado de tipo "Artist". Los subtipos deben cumplir los siguientes requisitos. Una infracción de los requisitos hará que AppSearchSession.setSchema inicie una excepción AppSearchException con el código de resultado de AppSearchResult.RESULT_INVALID_ARGUMENT. Considere un tipo Artist y un tipo Person, y Artist afirma que es un subtipo de Person y, después, cada propiedad de Person debe tener una propiedad correspondiente en Artist con el mismo nombre. Todas las propiedades que no son de documento en Person deben tener el mismo tipo que el tipo de la propiedad correspondiente en Artist. Por ejemplo, si "age" es una propiedad entera en Person, "age" también debe ser una propiedad entera en Artist, en lugar de una cadena. El tipo de esquema de cada propiedad de documento en Artist debe ser un subtipo del tipo de esquema de la propiedad de documento correspondiente en Persona, si existe dicha propiedad en Person. Por ejemplo, si "premios" es una propiedad de documento de tipo Award en Persona, el tipo de la propiedad "premios" en Artist debe ser un subtipo de Award, por ejemplo, ArtAward. Tenga en cuenta que cada tipo es un subtipo de sí mismo. Cada propiedad de Artist debe tener una cardinalidad más estricta o igual que la cardinalidad de la propiedad correspondiente en Persona, si existe dicha propiedad en Persona. Por ejemplo, si "premios" es una propiedad en Persona de cardinalidad OPCIONAL, la cardinalidad de la propiedad "premios" en Artist solo puede ser OBLIGATORIA o OPCIONAL. Regla: OBLIGATORIO < REPETIDO OPCIONAL < . No hay ninguna otra aplicación en las propiedades correspondientes en Artist, como el tipo de índice, el tipo de tokenizador, etc. Esta configuración se puede invalidar de forma segura. Se puede definir un tipo para tener varios elementos primarios, pero debe ser compatible con cada uno de sus elementos primarios en función de las reglas anteriores. Por ejemplo, si LocalBusiness se define como un subtipo de Place y Organization, se comprobará la compatibilidad de LocalBusiness con Place y la compatibilidad de LocalBusiness con Organización.

Referencia de Android para android.app.appsearch.AppSearchSchema.Builder.addParentType.

Las partes de esta página son modificaciones basadas en el trabajo creado y compartido por el Android y se usan según los términos descritos en creative Creative Commons 2.5 Attribution License.