I implemented some CDS views with associations on a SAP NETWEAVER 7.5 SP 19 (09/2020) system.
I used in the SEGW transaction the reference by data source feature to automatically create the ODATA types and associations from the CDS views and add them to a existing SEGW ODATA project.
Then I use that ODATA service in a SAPUI5 app.
Here is one of the guides i used: https://www.saplearners.com/create-odata-service-abap-cds-views-segw/
CDS view
The CDS view is named like /ID/VIEW_NAME_CDS.
The associations are renamed with as and get an underscore before the name. The name is then _assication_name. The underscore seems to be a convention by SAP to make the navigation property readable.
Result
In the SEGW project the wizard creates a Entity Type with the name: xidxview_name_cdsType
Every slash will be replaced by an x and at the end Type will be added.
The navigation property is named to_assication_name.
The association gets a name like assoc_0D6ADC4B279EADE543738376111F7216.
Goal
I want to change the name of the entity types, associations and navigation properties because I want some readable names in the sapui5 app
Clarification 2020/11/30: The name should also be changed in the SEGW transaction itself so that they are the same in SEGW and SAPUI5 because some months in the future annother developer will not think that I changed the names in the MPC_EXT class. At least I wouldn't think of that. :-)
Is this possible with annotations in the CDS view? Or any other way?
Example
#AbapCatalog.sqlViewName: 'ZTEST'
#AbapCatalog.compiler.compareFilter: true
#AbapCatalog.preserveKey: true
#AccessControl.authorizationCheck: #CHECK
#EndUserText.label: 'A test'
define view /ABC/SYSTEM_RESULT_CDS as
select from system as system
association [1..*] to /abc/s_mon_result as _monitoring_results on _monitoring_results.system_id = $projection.system_id
{
key system.system_id,
system.name,
_monitoring_results
}
group by system.system_id
Entity Type: xabcxsystem_result_cdsType
This a mix of camel case style and snake case. Not very readable.
Navigation Properties: to_monitoring_results
Is ok but i would like to have the oportunity to rename it.
Association: assoc_0D6ADC4B279EADE543738376111F7216
Not readable. Only if you click on it you see the 2 entities to which the association belongs.
You have to redefine DEFINE method of MPC_EXT class, the runtime artifact after service generation:
super->define( ).
DATA: lo_entity_type TYPE REF TO /iwbep/if_mgw_odata_entity_typ,
lo_entity_set TYPE REF TO /iwbep/if_mgw_odata_entity_set,
lo_property TYPE REF TO /iwbep/if_mgw_odata_property.
" for entity type
lo_entity_type = model->get_entity_type( 'C_Cfd_UsageType' ).
lo_entity_type->set_name( iv_name = 'CFDUsage' ).
" for association
lo_entity_type = model->get_association( 'C_CFD_Assoc' ).
lo_entity_set->set_name( iv_name = 'CFDAssociation' ).
" for entity set
lo_entity_set = model->get_entity_set( 'C_Cfd_Usage' ).
lo_entity_set->set_name( iv_name = 'CFD' ).
After that new names will be reflected in the service $metadata:
Related
When I save a new F# Record, I'm getting an extra column called Id# in the RavenDb document, and it shows up when I load or view the object in code; it's even being converted to JSON through my F# API.
Here is my F# record type:
type Campaign = { mutable Id : string; name : string; description : string }
I'm not doing anything very exciting to save it:
let save c : Campaign =
use session = store.OpenSession()
session.Store(c)
session.SaveChanges()
c
Saving a new instance of a record creates a document with the Id of campaigns/289. Here is the full value of the document in RavenDb:
{
"Id#": "campaigns/289",
"name": "Recreating Id bug",
"description": "Hello StackOverflow!"
}
Now, when I used this same database (and document) in C#, I didn't get the extra Id# value. This is what a record looks like when I saved it in C#:
{
"Description": "Hello StackOverflow!",
"Name": "Look this worked fine",
}
(Aside - "name" vs "Name" means I have 2 name columns in my document. I understand that problem, at least).
So my question is: How do I get rid of the extra Id# property being created when I save an F# record in RavenDb?
As noted by Fyodor, this is caused by how F# generates a backing field when you create a record type. The default contract resolver for RavenDB serializes that backing field instead of the public property.
You can change the default contract resolver in ravendb. It will look something like this if you want to use the Newtonsoft Json.Net:
DocumentStore.Conventions.JsonContractResolver <- new CamelCasePropertyNamesContractResolver()
There is an explanation for why this works here (see the section titled: "The explanation"). Briefly, the Newtonsoft library uses the public properties of the type instead of the private backing fields.
I also recommend, instead of having the mutable property on the Id, you can put the [<CLIMutable>] attribute on the type itself like:
[<CLIMutable>]
type Campaign = { Id : string; name : string; description : string }
This makes it so libraries can mutate the values while preventing it in your code.
This is a combination of... well, you can't quite call them "bugs", so let's say "non-straightforward features" in both F# compiler and RavenDb.
The F# compiler generates a public backing field for the Id record field. This field is named Id# (a standard pattern for all F# backing fields), and it's public, because the record field is mutable. For immutable record fields, backing fields will be internal. Why it needs to generate a public backing field for mutable record fields, I don't know.
Now, RavenDb, when generating the schema, apparently looks at both properties and fields. This is a bit non-standard. The usual practice is to consider only properties. But alas, Raven picks up the public field named Id#, and makes it part of the schema.
You can combat this problem in two ways:
First, you could make the Id field immutable. I'm not sure whether that would work for you or RavenDb. Perhaps not, since the Id is probably generated on insert.
Second, you could declare your Campaign not as an F# record, but as a true class:
type Campaign( id: int, name: string, description: string ) =
member val Id = id with get, set
member val name = name
member val description = description
This way, all backing fields stay internal and no confusion will arise. The drawback is that you have to write every field twice: first as constructor argument, then as class member.
i´m using the Papa's course CCJS code to investigate Breeze.js and SPA. Using this code i´m trying to manage aditional information that cames from server but that is not an Entity contained in the Metadata that cames from EntityFramework.
So i created a NO-DB class called Esto and a Server method like Lookups:
[HttpGet]
public object Informacion()
{
var a = new Esto(....);
var b = new Esto(.....);
var c = new Esto(......);
return new {a,b,c};
}
then in model.js inside configureMetadataStore i call:
metadataStore.addEntityType({
shortName: "Esto",
namespace:"CodeCamper",
dataProperties:{
id: {dataType: breeze.DataType.Int32,isPartOfKey: true},
name: {dataType: breeze.DataType.String}
}
};
and also define in the model entityNames array: esto:'Esto' as an Entity
now in the context.js i load this creating a server side method like getLookups but called getInformacion:
function getInformacion(){
return EntityQuery.from('Informacion')
.using(manager).execute()
}
and then inside primeData in the success method call this:
datacontext.informacion = {
esto: getLocal('Esto',nombre)};
where getLocal is:
function getLocal(resource, ordering)
{
var query = EntityQuery.from(resource).orderBy(ordering);
return manager.executeQueryLocally(query);
}
I get an error in the query contained in the getLocal that states that Can not find EntityType for either entityTypeName: 'undefined' or resourceName:'Esto'.
What i´m doing wrong?
Thanks
You were almost there! :-) Had you specified the target EntityType in the query I think it would have worked.
Try this:
var query = EntityQuery.from(resource).orderBy(ordering).toType('Esto');
The toType() method tells Breeze that the top-level objects returned by this query will be of type Esto.
Why?
Let's think about how Breeze interprets a query specification.
Notice that you began your query, as we usually do, by naming the resource which will supply the data. This resource is typically a path segment to a remote service endpoint, perhaps the name of a Web API controller method ... a method named "Foos".
It's critical to understand that the query resource name is rarely the same as the EntityType name! They may be similar - "Foos" (plural) is similar to the type name "Foo" (singular). But the resource name could be something else. It could be "GetFoos" or "GreatFoos" or anything at all. What matters is that the service method returns "Foo" entities.
Breeze needs a way to correlate the resource name with the EntityType name. Breeze doesn't know the correlation on its own. The toType() method is one way to tell Breeze about it.
Why do remote queries work without toType()?
You generally don't add toType() to your queries. Why now?
Most of the time [1], Breeze doesn't need to know the EntityType until after the data arrive from the server. When the JSON query results includes the type name (as they do when they come from a Breeze Web API controller for example), Breeze can map the arriving JSON data into entities without our help ... assuming that these type names are in metadata.
Local cache queries are different
When you query the cache ... say with executeQueryLocally ... Breeze must know which cached entity-set to search before it can query locally.
It "knows" if you specify the type with toType(). But if you omit toType(), Breeze has to make do with the query's resource name.
Breeze doesn't guess. Instead, it looks in an EntityType/ResourceName map for the entity-set that matches the query resource name.
The resource name refers to a service endpoint, not a cached entity-set. There is no entity-set named "Informacion", for example. So Breeze uses an EntityType/ResourceName map to find the entity type associated with the query resource name.
EntityType/ResourceName
The EntityType/ResourceName map is one of the items in the Breeze MetadataStore. You've probably never heard of it. That's good; you shouldn't have to think about it ... unless you do something unusual like define your own types.
The map of a new MetadataStore starts empty. Breeze populates it from server metadata if those metadata contain EntityType/Resource mappings.
For example, the Breeze EFContextProvider generates metadata with mappings derived from DbSet names. When you define a Foo class and exposed it from a DbContext as a DbSet named "Foos", the EFContextProvider metadata generator adds a mapping from the "Foos" resource name to the Foo entity type.
Controller developers tend to use DbSet names for method names. The conventional Breeze Web API controller "Foo" query method looks like this:
[Get]
public IQueryable<Foo> Foos() {...}
Now if you take a query such as this:
var query = EntityQuery.from('Foos').where(...);
and apply it to the cache
manager.query.executeLocally(query).then(...);
it just works.
Why? Because
"Foos" is the name of a DbSet on the server
The EFContextProvider generated metadata mapping ["Foos" to Model.Foo]
The Web API Controller offers a Foos action method.
The BreezeJS query specifies "Foos"
The executeLocally method finds the ["Foos"-to-Model.Foo] mapping in metadata and applies the query to the entity-set for Foo.
The end-to-end conventions work silently in your favor.
... until you mention a resource name that is not in the EntityType/ResourceName map!
Register the resource name
No problem!
You can add your own resource-to-entity-type mappings as follows:
var metadataStore = manager.metadataStore;
var typeName = 'some-type-name';
var entityType = metadataStore.getEntityType(typeName);
metadataStore.setEntityTypeForResourceName(resource, entityType);
Breeze is also happy with just the name of the type:
metadataStore.setEntityTypeForResourceName(resource, typeName);
In your case, somewhere near the top of your DataContext, you could write:
var metadataStore = manager.metadataStore;
// map two resource names to Esto
metadataStore.setEntityTypeForResourceName('Esto', 'Esto');
metadataStore.setEntityTypeForResourceName('Informacion', 'Esto');
Don't over-use toType()
The toType() method is a good short-cut solution when you need to map the top-level objects in the query result to an EntityType. You don't have to mess around with registering resource names.
However, you must remember to add toType() to every query that needs it. Configure Breeze metadata with the resource-to-entity-type mapping and you'll get the desired behavior every time.
Notes
[1] "Most of the time, Breeze doesn't need to know the EntityType until after the data arrive from the server." One important exception - out of scope for this discussion - is when the query filter involves a Date/Time.
I think that the problem here is that you are assuming that entity type names and resource names are the same thing. A resource name is what is used to execute a query
var q = EntityQuery.from(resourceName);
In your case the "resourceName" is "Informacion" and the entityType is actually "Esto". Breeze is able to make this connection on a remote query because it can examine the results returned from the server as a result of querying "Informacion" and seeing that they are actually "Esto" instances. This is not possible for a local query because Breeze doesn't know what local collection to start from.
In this case you need to give Breeze a little more information via the MetadataStore.setEntityTypeForResourceName method. Something like this:
var estoType = manager.metadataStore.getEntityType("Esto");
manager.metadataStore.setEntityTypeForResourceName("Informacion", estoType);
Note that this is not actually necessary if the resource was defined via Entity Framework metadata, because Breeze automatically associates all EF EntitySet names to resource names, but this information isn't available for DTO's.
Note also that a single entity type can have as many resourceNames as you like. Just make sure to register the resourceNames before you attempt a local query.
Above is a simplified version of our domain model. NotificationOrder has a reference to an instance of a sub class (consider ReferenceNumberBase logically abstract).
Problem:
I want a query to return all NotificationOrders that satisfies XYZ and I want that query to eagerly load all referenced instances of CustomerCase (including all related objects of that graph, except Group forget about that issue for the moment).
I've tried searching for a solution to this, but all I've found are solutions to problems equivalent of querying for CustomerCase as a root object directly.
I'd like something like this:
var query = ObjectContext.CreateObjectSet<NotificationOrder>.Where(e => e.NotificationType == "Foo");
return ((ObjectSet<NotificationOrder>) query).Include("ReferenceNumberBase");
However, that won't load the Vehicle instance of CustomerCase or any of the other related objects. How can I express this so EF understands the eager load I want (I'd very much like to avoid multiple roundtrips / notification order)?
NOTE: Since CustomerCase is a derived type I can't do normal transitive include using something like this:
var query = ObjectContext.CreateObjectSet<NotificationOrder>.Where(e => e.NotificationType == "Foo");
return ((ObjectSet<NotificationOrder>) query).Include("ReferenceNumberBase.Vehicle"); //
since the Vehicle property is a member of the derived CustomerCase type, and not the ReferenceNumberBase type and instead we get errors like:
"The EntityType 'Model.ReferenceNumberBase' does not declare a navigation property with the name 'Vehicle'."
Neither can I use query.OfType<CustomerCase>... since the query type is NotificationOrder, and not ReferenceNumberBase (or can I somehow?).
ps. We are using self tracking POCO entities with EF4 (have not upgraded to 4.1 yet)
EDIT: I've searched some more, and as of about a year ago this looks to have been a limitation of the Include() method (at least at that time). Is this accurate and has this been adressed since then? [sources below]
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/a30351ab-5024-49a5-9eb4-798043a2b75d
http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions/suggestions/1057763-inheritance-eager-loading?ref=title
https://connect.microsoft.com/VisualStudio/feedback/details/594289/in-entity-framework-there-should-be-a-way-to-eager-load-include-navigation-properties-of-a-derived-class
I've got a stored procedure that has a couple parameters that are nested tables.
CREATE TYPE FOO_ARRAY AS TABLE OF NUMBER;
CREATE TYPE BAR_ARRAY AS TABLE OF INTEGER;
CREATE PROCEDURE Blah(
iFoos IN FOO_ARRAY,
iBars IN BAR_ARRAY,
oResults OUT SOMECURSORTYPE
) AS
BEGIN
OPEN oResults FOR
SELECT *
FROM SomeTable T
JOIN TABLE(iFoos) foos ON foos.column_value = T.foo
JOIN TABLE(iBars) bars ON bars.column_value = T.bar;
END
Using ODP.NET (Oracle.DataAccess.dll), is there a way to call this stored procedure and pass arrays into these parameters? The only way I've found to pass arrays is if the parameter type is an associative array (a different type of collection that isn't accessible within SQL).
I made it work this way:
Create a type in the database like "create or replace TYPE NT_LNG IS TABLE OF varchar(2);"
Create a Class implementing IOracleCustomType and INullable (SimpleStringArray)
Create a Class implementing IOracleCustomTypeFactory (SimpleStringArrayFactory). Mark it with this attribute "[OracleCustomTypeMappingAttribute("KNL.NT_LNG")]"
and you pass the parameter like this:
SimpleStringArray sa1 = new SimpleStringArray();
sa1.Array = new String[]{"aaa","bbb"};
OracleParameter param = new OracleParameter("p_lngsrc", OracleDbType.Array, sa1, ParameterDirection.Input);
param.UdtTypeName = "KNL.NT_LNG";
Good Luck
Oracle also offers a free tool to generate a custom .NET class that maps to your nested table type:
Download "Oracle Developer Tools for Visual Studio" (free), open Server Explorer, open "User Defined Types" node, find your user defined type, right click and choose "Generate Custom Class".
Here's a walkthrough to get you started with UDTs in general:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/hol08/dotnet/udt/udt_otn.htm
I'm working on an application at the moment in ASP.NET MVC which has a number of look-up tables, all of the form
LookUp {
Id
Text
}
As you can see, this just maps the Id to a textual value. These are used for things such as Colours. I now have a number of these, currently 6 and probably soon to be more.
I'm trying to put together an API that can be used via AJAX to allow the user to add/list/remove values from these lookup tables, so for example I could have something like:
http://example.com/Attributes/Colours/[List/Add/Delete]
My current problem is that clearly, regardless of which lookup table I'm using, everything else happens exactly the same. So really there should be no repetition of code whatsoever.
I currently have a custom route which points to an 'AttributeController', which figures out the attribute/look-up table in question based upon the URL (ie http://example.com/Attributes/Colours/List would want the 'Colours' table). I pass the attribute (Colours - a string) and the operation (List/Add/Delete), as well as any other parameters required (say "Red" if I want to add red to the list) back to my repository where the actual work is performed.
Things start getting messy here, as at the moment I've resorted to doing a switch/case on the attribute string, which can then grab the Linq-to-Sql entity corresponding to the particular lookup table. I find this pretty dirty though as I find myself having to write the same operations on each of the look-up entities, ugh!
What I'd really like to do is have some sort of mapping, which I could simply pass in the attribute name and get out some form of generic lookup object, which I could perform the desired operations on without having to care about type.
Is there some way to do this to my Linq-To-Sql entities? I've tried making them implement a basic interface (IAttribute), which simply specifies the Id/Text properties, however doing things like this fails:
System.Data.Linq.Table<IAttribute> table = GetAttribute("Colours");
As I cannot convert System.Data.Linq.Table<Colour> to System.Data.Linq.Table<IAttribute>.
Is there a way to make these look-up tables 'generic'?
Apologies that this is a bit of a brain-dump. There's surely imformation missing here, so just let me know if you'd like any further details. Cheers!
You have 2 options.
Use Expression Trees to dynamically create your lambda expression
Use Dynamic LINQ as detailed on Scott Gu's blog
I've looked at both options and have successfully implemented Expression Trees as my preferred approach.
Here's an example function that i created: (NOT TESTED)
private static bool ValueExists<T>(String Value) where T : class
{
ParameterExpression pe = Expression.Parameter(typeof(T), "p");
Expression value = Expression.Equal(Expression.Property(pe, "ColumnName"), Expression.Constant(Value));
Expression<Func<T, bool>> predicate = Expression.Lambda<Func<T, bool>>(value, pe);
return MyDataContext.GetTable<T>().Where(predicate).Count() > 0;
}
Instead of using a switch statement, you can use a lookup dictionary. This is psuedocode-ish, but this is one way to get your table in question. You'll have to manually maintain the dictionary, but it should be much easier than a switch.
It looks like the DataContext.GetTable() method could be the answer to your problem. You can get a table if you know the type of the linq entity that you want to operate upon.
Dictionary<string, Type> lookupDict = new Dictionary<string, Type>
{
"Colour", typeof(MatchingLinqEntity)
...
}
Type entityType = lookupDict[AttributeFromRouteValue];
YourDataContext db = new YourDataContext();
var entityTable = db.GetTable(entityType);
var entity = entityTable.Single(x => x.Id == IdFromRouteValue);
// or whatever operations you need
db.SubmitChanges()
The Suteki Shop project has some very slick work in it. You could look into their implementation of IRepository<T> and IRepositoryResolver for a generic repository pattern. This really works well with an IoC container, but you could create them manually with reflection if the performance is acceptable. I'd use this route if you have or can add an IoC container to the project. You need to make sure your IoC container supports open generics if you go this route, but I'm pretty sure all the major players do.