I have a MongoDB Collection with more then 400 fields, How can i get all the fields without defining each of them in the model. Right now i am only getting the fields that i have defined in the model. I have tried passing no arguments in the filter but still getting only the defined fields.
Thanks!
Disclaimer: I am a maintainer of LoopBack 4. The text below is cross-posted from our documentation in https://loopback.io/doc/en/lb4/Model.html#using-the-juggler-bridge, see also my pull request #1745 that introduced strict mode.
Models are defined primarily by their TypeScript class. By default, classes forbid additional properties that are not specified in the type definition. The persistence layer respects this constraint and configures underlying PersistedModel classes to enforce strict mode.
To create a model that allows both well-defined but also arbitrary extra properties, you need to disable strict mode in model settings and tell TypeScript to allow arbitrary additional properties to be set on model instances.
#model({settings: {strict: false}})
class MyFlexibleModel extends Entity {
#property({id: true})
id: number;
// Define well-known properties here
// Add an indexer property to allow additional data
[prop: string]: any;
}
Related
Is there any integration point allowing to add a meta-field on all indexed documents transparently, right before they are indexed, similarly to _hibernate_class?
Currently using Hibernate 5.11
As discussed over the chat, the only option in Search 5 is to use the programmatic mapping API to add a class bridge to every single indexed entity type.
In Search 6, you can use the new programmatic mapping API to add a type bridge to the Object type, and it will be applied to every type. It will also be applied to embedded types, though, so that may not be what you're after.
After release of EF Core 2.2 it is now possible to have both single and collection values of owned types.
In contrast to classical navigational properties owned types are always included in the entity, so owned types looks like a natural way of describing the shape of an aggregate.
Are there any DDD related use cases where classical navigation properties are still better?
Update 1
Prior to 2.2 I was able to call modelBuilder.Entity<OwnedType> and configure alternative key.
Now with 2.2 I started getting errors during migration: primary key is not defined for the entity. However, ReferenceOwnershipBuilder class which is passed as a parameter to buildAction lambda in method OwnsOne does not contain HasAlternateKey. This is currently a known limitation.
Update 2
Currently owned types do not support inheritance. This may be critical for some use cases.
I am a new learner on OrientDB and have this question about schema. How to define a schema-full mode for a new class -say person class? Similarly how to define the schema-hybrid mode -using sql?
Somehow I can't make out this from the documentation.
Thanks,
DBuserN
The schema-full mode is controlled on a per-class basis and can be enabled or disabled using the STRICTMODE keyword. For example:
alter class Person strictmode=true;
For reference
http://orientdb.com/docs/2.0/orientdb.wiki/SQL-Alter-Class.html
Schema-full Enables strict-mode at a class-level and sets all fields as mandatory.
Schema-less Enables classes with no properties. Default is non-strict-mode, meaning that records can have arbitrary fields.
Schema-hybrid Enables classes with some fields, but allows records to define custom fields. This is also sometimes called schema-mixed.
You can define schema, as you create the structure of your DB. So if you define properties on a class it will be schema-full. A class without properties and it will be schema-less etc...
You can fine more information on official documentation.
Hope it helps.
i'm trying to figure wether there's a difference betweeen anotating (let's take #id as an example) a getter method and the concerned field directly , in case i annotate the field , does JPA use some kind of reflection to invok the corresponding getter ?
because in my case i'm trying to obfuscate my entity classes , so i'm looking for a way to keep the business logic since the getters will be renamed into something like aaa() .
Here's what the section 2.3.1 of the JPA2 specification says:
By default, a single access type (field or property access) applies to
an entity hierarchy. The default access type of an entity hierarchy is
determined by the placement of mapping annotations on the attributes
of the entity classes and mapped superclasses of the entity hierarchy
that do not explicitly specify an access type. An access type is
explicitly specified by means of the Access annotation[6], as
described in section 2.3.2. When annotations are used to define a
default access type, the placement of the mapping annotations on
either the persistent fields or persistent properties of the entity
class specifies the access type as being either field- or
property-based access respectively.
When field-based access is used, the object/relational mapping annotations for the entity class annotate the instance variables, and
the persistence provider runtime accesses instance variables directly.
All non-transient instance variables that are not annotated with the
Transient annotation are persistent.
When property-based access is used, the object/relational mapping annotations for the entity class annotate the getter property
accessors[7], and the persistence provider runtime accesses persistent
state via the property accessor methods. All properties not annotated
with the Transient annotation are persistent.
Mapping annotations must not be applied to fields or properties that are transient or Transient.
All such classes in the entity hierarchy whose access type is
defaulted in this way must be consistent in their placement of
annotations on either fields or properties, such that a single,
consistent default access type applies within the hierarchy. Any
embeddable classes used by such classes will have the same access type
as the default access type of the hierarchy unless the Access
annotation is specified as defined below. It is an error if a default
access type cannot be determined and an access type is not explicitly
specified by means of annotations or the XML descriptor. The behavior
of applications that mix the placement of annotations on fields and
properties within an entity hierarchy without explicitly specifying
the Access annotation is undefined.
So, if you want to avoid problems with the obfuscation, then annotate the fields and not the getters, consistently, or use the #Access annotation to force field access type.
JPA allows for two types of access to the data of a persistent class. Field access which means that it maps the instance variables (fields) to columns in the database and Property access which means that is uses the getters to determine the property names that will be mapped to the db. What access type it will be used is decided by where you put the #Id annotation (on the id field or the getId() method).
I have an Entity called "Product", this entity, through table mapping, merges 6 tables that have a 1 to 1..0 relationship with "Products". This all works wonderfully. There is another property I want to add to "Products", which is sBBR_rate, this value is not in a table that has a direct 1 to 1..0 relationship, it is related through a link table as below:
When I import the two tables into the EDM, I can't see a way in the "Mapping Details" of
"Product" to reference the sBBR_rate. I can reference RatesLink and link that to the "Products" primary key, however, I cannot reference the BBR table.
The methods I can think of to work "around" this is are as follows:
Create a view, reference the view in the EDM.
Create an SP and use a function import to retrieve the BBR when it is required.
Create a "Rates" entity in the EDM that can then draw down the sBBR_rate into it. Navigate to the Products BBR through Product.Rates.sBBR_rate.
Is there a better way I can do this that doesn't feel so much like a fudge? Perhaps by directly editing the XML of the Mapping or Conceptual layers of the EDM?
Thanks for your input.
Because the multiplicities on the Product -> RatesLink and RatesLink -> BBR relationships are 0 to 1, you should be able to access the sBBR_rate from a Product instance like this:
myProductInstance.RatesLink.BBR.sBBR_rate
I can see on the EDM screenshot that RatesLink has a Product and BBR property, which would indicate this should be available - is it?
On a side note, if it makes sense for the sBBR_rate property to commonly be accessed directly from Product, you might want to follow the law of demeter and create a property on Product which returns it directly.
The model we are using is to extend entities by using partial classes which we've found useful so we can get additional properties in the autogenerated classes (we are using a POCO T4 template to autogen but I believe this would work just as well with the default entity object generation).
So we would have
//.. this one is from the T4 template
public partial class Product
{
//.. all the autogenerated methods
}
and in a separate file that isn't autogened
//.. now in a separate file created by me
public partial class Product
{
//.. my custom properties and methods to make the entities more usable
public string BBRRate
{
get {return this.RatesLink.BBR.sBBR_rate; }
}
}
This means that I can just do
myProduct.BBRRte
I know there are other ways to do this by amending the edmx file but this one we found easy to implement. You just need to watch performance because you are potentially loading extra data. Also we did this with LazyLoading turned on but with more work you wouldn't have to
We also experimented with hooking into the ObjectMaterialized event in the ObjectContext class to preload some of these properties. Using a custom interface i.e. IMaterialisable we could check if the object was of that type then call a method (Materialise) to prepopulate some of the properties. This seems like a good idea but we didn't widely use it - it was easy to load up too much stuff. If you do the load on the properties in the partial classes then it becomes more efficient. Just my experience.
Anyway - as always an interesting question and good luck again with your dev.
EDIT
There is a rule that everything in the store layer must be represented some way in your conceptual layer. Therefore removing the tables from the conceptual layer but bring through some of the properties I don't think will work in it's gross form. Therefore I can think of two further options
Create a View on the database and bring that in as you have already mentioned. TBH this is what I would do.
Use the DefiningQuery element directly in your xml (the store layer) and map the query through to a custom entity of your exact design. Julie Lerman describes this as the ultimate escape hatch for Entity Framework.
Remember though - if you manual amend the XML in point 2 then you lose the ability to automatically update the module through the IDE
I ended up creating a view and then linking this view in the EDM, this worked a treat.