What is the use of cardinality attribute in #property annotation in apache felix scr?
It is well explained in Apache Docs here, what is that you are not clear about?
cardinality
Defaut: Depends on property value(s)
SCR Descriptor: --
Metatype Descriptor: AD.cardinality
Defines the cardinality of the property and its collection type. If the cardinality is negative, the property is expected to be stored
in a java.util.Vector (primitive types such as boolean are boxed in
the Wrapper class), if the cardinality is positive, the property is
stored in an array (primitve types are unboxed, that is Boolean type
values are stored in boolean[]()). The actual value defines the
maximum number of elements in the vector or array, where
Integer.MININT describes an unbounded Vector and Integer.MAXINT
describes an unbounded array. If the cardinality is zero, the property
is a scalar value. If the defined value of the property is set in the
value attribute, the cardinality defaults to 0 (zero for scalar
value). If the property is defined in one or more properties starting
with values, the cardinality defaults to Integer.MAX_INT, that is an
unbounded array.
It refers to what type of property are you storing and if it has single (SCALAR) value or multiple value (UNBOUNDED), read more in scr-javadoc-tags
Related
I designed an entity relationship diagram (ERD) with the goal of creating two child entities (INSTITUTION and SPACECRAFT) of a parent entity (LOCATION), which is distinguished depending on the value of a boolean attribute (IS_SPACECRAFT). Implementing this in MongoDB, I'd like to link the INSTITUTION entity to another separate entity when IS_SPACECRAFT is false (0), and the SPACECRAFT entity to this other separate entity when IS_SPACECRAFT is true (1).
Right now, I am doing this manually by creating two attributes (SPACECRAFT_ID and INSTITUTION_ID) in this unrelated entity and pasting the object ID of either the INSTITUTION or SPACECRAFT entity in this attribute depending on the value of IS_SPACRECRAFT. But this inevitably leads to one of those attributes being NULL, which I think is poor database design and is something I'd like to avoid. With that in mind, is there a way to link another entity (i.e., as a foreign key) depending on a Boolean value in MongoDB?
Attached below is the ERD I mentioned earlier so the hierarchy is clear. The discriminator (d) is meant to represent a disjoint (overlapping) subtype, and the double lines represent a total completeness constraint, such that all the member of the parent LOCATION entity are in either SPACECRAFT or LOCATION, but not both.
For reference, a disjoint subtype is defined as:
Disjoint subtypes, also known as nonoverlapping subtypes, are subtypes that contain a unique subset of the supertype entity set; in other words, each entity instance of the supertype can appear in only one of the subtypes.
And total completeness is defined as:
The completeness constraint specifies whether each entity supertype occurrence must also be a member of at least one subtype. The completeness constraint can be partial or total. Partial completeness means that not every supertype occurrence is a member of a sub-type; some supertype occurrences may not be members of any subtype. Total completeness means that every supertype occurrence must be a member of at least one subtype.
https://www.google.com/books/edition/Database_Systems_Design_Implementation_M/4JN4CgAAQBAJ
I use 'RealmSwift' to create a Realm Database in my app. Consider a subclass of 'Object' that I use to be 'ClassA'. The 'ClassA' and its properties can be simply described as below(avoiding actual code for brevity):
ClassA: Object
-prop1
-prop2
-prop3
-prop4
-prop5
-prop6
I want to have to two indexes on the 'ClassA'. To be specific I want each index to be a compound index. Lets call the two Indexes as 'Index1' & 'Index2'. And by compound I mean an Index can have multiple properties. So lets define the two Indexes as below:
Index1: prop1, prop2, prop6
Index2: prop3, prop4, prop5
I need these compound indexes, in order to have faster fetches, in case I have the values for those particular properties. This is of critical importance for my application.
Providing indexes on Real Objects using 'RealmSwift' is done by overriding Object.indexedProperties() by returning an array of String containing the names of properties we want to index.
I want to know if this will create a separate index for each property or a single compound index for all the properties.
AS I understand the documentation Object.indexedProperties() will create an index for each property that you return, but no compound index.
What you can do to get around this is to create new properties on your objects which combine the properties you want to use for your compound index.
Example:
Create a new property indexProp126 by concatenating prop1, prop2 and prop6 to a String (just as an example, there are probably more efficient ways like hashes etc. depending on what the type and content of those properties really is) and use this as the index then.
This is probably an obvious question, but I'm not seeing it in Amazon's documentation.
Can I store documents and key-value pairs in the same DynamoDB instance? Or can an instance only have one type?
I also don't see how to specify the object type when writing an item.
The wording is confusing. The primary keys do need to be one Data type.
DynamoDB supports many different data types for attributes within a
table. They can be categorized as follows:
Scalar Types – A scalar type can represent exactly one value. The scalar types are number, string, binary, Boolean, and null.
Document Types – A document type can represent a complex structure with nested attributes—such as you would find in a JSON document. The
document types are list and map.
Set Types – A set type can represent multiple scalar values. The set types are string set, number set, and binary set.
When you create a table or a secondary index, you must specify the
names and data types of each primary key attribute (partition key and
sort key). Furthermore, each primary key attribute must be defined as
type string, number, or binary.
DynamoDB is a NoSQL database and is schemaless. This means that, other
than the primary key attributes, you don't have to define any
attributes or data types when you create tables. By comparison,
relational databases require you to define the names and data types of
each column when you create a table.
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html
JPA specification says:
Only the values of like types are permitted to be compared. A type is like another type if they correspond to the same Java language type, or if one is a primitive Java language type and the other is the
wrappered Java class type equivalent (e.g., int and Integer are like types in this sense). There is one
exception to this rule: it is valid to compare numeric values for which the rules of numeric promotion
apply. Conditional expressions attempting to compare non-like type values are disallowed except for
this numeric case.
Note that the arithmetic operators and comparison operators are permitted to be applied to
state fields and input parameters of the wrappered Java class equivalents to the primitive
numeric Java types.
Two entities of the same abstract schema type are equal if and only if they have the same primary key
value.
Only equality/inequality comparisons over enums are required to be supported.
Comparisons over instances of embeddable class or map entry types are not supported.
Does this mean that queries
where entity1 = entity2
and
where entity1.id = entity2.id
should always give the same result (and have same performance) or are there some edge cases (e.g. if one of entities is null)? Is the behavior the same in all implementations?
These can be different, depending where your entity comes from, and your JPA implementation.
entity1 = entity2, may allow the JPA implementation to optimize out a join in certain cases.
In most cases, we can map a field in a table either to a property or we can map it using conditional mapping, but not both. Only exception is if condition is set to Is NotNull, since then we can also map to a column.
a) Is this the reason why we are able to map a DB column only once - namely, if field was allowed to have both a property mapping and a conditional mapping, then property mapping would tell EF to retrieve all table rows, while conditional mapping would tell EF to retrieve only those rows that satisfy the condition?!
b) If my reasoning under a) is correct, then why is field allowed to have both mappings when condition is set to Is NotNull? Why won't that create a conflict?
Thank you
Mapping with condition Is NotNull has special meaning because it requires subsequent change in your model. The mapped property in the model must not be nullable. So your column in the database is nullable, your mapping condition filters all records with null value and your property always receives only records with non-null values. Also you can never assign null to the property.
In case of common condition with value equality this special behaviour is not possible.