In Dynamics 365 Finance and Operations, I created data entity for WMSOrderTrans table. Let's say it's SalesOrderPickingListLines. I've added EntityKey with two fields: orderId and RecId (the same index exists in the table itself, named OrderIdx).
The data entity works without an issue, key fields are in the metadata, I can get a record using data/SalesOrderPickingListLines(dataAreaId='inpl',orderId='myorder',RecId1=myrecordid)
The problem is, that now I need to create OData action for it, but it seems that that the key fields are not seen in the action. I am using Power Automate to test it.
I created a function in the entity's class with this code:
[SysODataActionAttribute('SetPickQuantity', true)]
public real setPickQuantity(InventQty _qty)
{
WMSOrderTrans _wmsOrderTrans;
select firstonly forupdate _wmsOrderTrans
where _wmsOrderTrans.orderId == this.orderId && _wmsOrderTrans.RecId == this.RecId1;
// some code to proceed
return _wmsOrderTrans.Qty;
}
The OData action is seen by Power Automate, but there are no key fields (except Company), so I am unable to perform this action for any record.
Usually it works without doing any other steps so that's why I'm here. The only difference with this and my previous work is that the source table (WMSOrderTrans) does not have a natural key, its index is RecId field. But I am not sure if this is the issue here. Any help will be appreciated.
Related
Does loopback 3 support filters on JSON field of a table ? I am using MySQL database.
For example, we create table 'events' -
CREATE TABLE events(
id int auto_increment primary key,
event_name varchar(255),
visitor varchar(255),
properties json,
browser json
);
Is there any way to apply filter on json fields 'properties' and 'browser' ?
First of all, MySQL doesn't index JSON column (there is workaround but not supported natively), if you go with MySQL, it can be problem in the near feature.
It think it is not possible because doc says that:
Data source connectors for relational databases don’t support filtering nested properties.
However you can implement your own logic for build-in methods via using operation hooks.
For example
Model - the constructor of the model that will be queried
query - the query containing fields where, include, order, etc.
MyModel.observe('access', function **queryToJsonField**(ctx, next) {
// operation goes here
next();
});
More detailed explanation can be found at doc
I'm researching whether to try Doctrine2 or not. One thing that scares me is the over SELECTing of columns I don't need (ie. consider lots of varchars being selected unnecessarily).
You might ask: but don't you want your full entity object filled? Yes, unless I'm looking for an array hydration. However, many times I don't need the full aggregation filled. Take the association shown below. If I query the Users table with a JOIN on Address, will all the columns from the address table be SELECTed as well (and therefore populated into an address object inside of users object)? Now imagine we have more JOINs. This could get really bad. What if I only want the fields from User populated in just a users only object? I guess I'm a little confused at what Doctrine is doing behind the scenes with associations and query JOINs.
/** #Entity **/
class User
{
// ...
/**
* #ManyToOne(targetEntity="Address")
* #JoinColumn(name="address_id", referencedColumnName="id")
**/
private $address;
}
/** #Entity **/
class Address
{
// ...
}
So does Doctrine2 populate all the fields of all the objects within the aggregate after a query (unless I specifiy partial)?
It depends on your query, but generally it is not implicit.
Using the query builder, you can fetch the associated record like this:
<?php
$qb = $em->createQueryBuilder();
$query = $qb->select(array("u", "a"))
->from("User", "u")
->innerJoin("u.address", "a")
->getQuery();
In the select() statement you specify what to fetch, in this case you get both.
If you only fetch the User records, then when you get the associated record with $user->getAddress(), Doctrine will make the query on the fly and hydrate the Address record for you.
That said, performance wise it is better to select both entities so Doctrine will make only one query and not 1+N queries
I'm using servicestack and i'm planning to use ormlite for the data access layer.
I've these tables (SQL Server 2005)
Table ITEM
ID PK
...
Table SUBITEM1
ID PK FK -> ITEM(ID)
...
Table SUBITEM2
ID PK FK -> ITEM(ID)
...
Table POST
ID PK
...
Table COMMENT
ID PK
...
Table DOWNLOAD
ID PK
...
Table POST_COMMENT
ID PK
POST_ID FK -> POST(ID)
COMMENT_ID FK -> COMMENT(ID)
Table DOWNLOAD_COMMENT
ID PK
DOWNLOAD_ID FK -> DOWNLOAD(ID)
COMMENT_ID FK -> COMMENT(ID)
I created a class for each table and mapped them using annotations (autoincrement, references, etc).
I decided to creare a repository for each "entity" (item, post, comment, download).
Each repository contains the basic CRUD logic,
eg. 1 CommentRepository has a Save(Comment comment, Object relationship) that performs db.Insert(comment, relationship) where relationship is PostComment or DownloadComment.
eg. 2 PostRepository has a Save(Post p) that performs the insert into POST.
I'm not sure about this solution because the repository interface is different and I can't do polymorphic queries.
Can you provide any advice to improve my DAL?
Thank you for your attention.
I'm not a fan of forced artificial abstraction so I don't like starting with a repository for every entity as it will just lead to un-necessary code-bloat. I like to start with only 1 repository for all entities encapsulating all data access and refactor naturally out when it gets too big.
I don't know enough of your domain to know what the best RDBMS layout is but I also like to avoid creating un-necessary tables where possible and will look to blob non-aggregate root data, e.g. if SubItem can only applies and is not meaningful outside the context of its parent Item, then I would just blob it saving a couple of tables, e.g:
class Item {
int Id; //PK, AutoIncr
List<SubItem> SubItem;
}
Rather than the separate Many : Many tables, I would just maintain it on the single Comment table, e.g:
class Comment {
int Id; //PK, AutoIncr
string CommentType; //i.e. Post or Download
int RefId;
string Comment;
}
So my repository would mimic the data access patterns required for fulfilling the Web Request, something like:
class BlogRepository {
void AddCommentToPost(int postId, Comment comment);
void AddCommentToDownload(int downloadId, Comment comment);
}
Good morning. I have been looking all over trying to answer this question.
If you have a table that has foreign keys to another table, and you want results from both tables, using basic sql you would do an inner join on the foreign key and you would get all the resulting information that you requested. When you generate your JPA entities on your foreign keys you get a #oneToone annotation, #oneToMany, #ManyToMany, #ManyToOne, etc over your foreign key columns. I have #oneToMany over the foreign keys and a corresponding #ManyToOne over the primary key in the related table column I also have a #joinedON annotation over the correct column... I also have a basic named query that will select everything from the first table. Will I need to do a join to get the information from both tables like I would need to do in basic sql? Or will the fact that I have those annotations pull those records back for me? To be clear if I have table A which is related to Table B based on a foreign key relationship and I want the records from both tables I would join table A to B based on the foreign key or
Select * From A inner Join B on A.column2 = B.column1
Or other some-such non-sense (Pardon my sql if it is not exactly correct, but you get the idea)...
That query would have selected all column froms A and B where those two selected column...
Here is my named query that I am using....
#NamedQuery(name="getQuickLaunch", query = "SELECT q FROM QuickLaunch q")
This is how I am calling that in my stateless session bean...
try
{
System.out.println("testing 1..2..3");
listQL = emf.createNamedQuery("getQuickLaunch").getResultList();
System.out.println("What is the size of this list: number "+listQL.size());
qLaunchArr = listQL.toArray(new QuickLaunch[listQL.size()]);
}
Now that call returns all the columns of table A, but it lack's the column's of table B. My first instinct would be to change the query to join the two tables... But that kind of makes me think what is the point of using JPA then if I am just writing the same queries that I would be writing anyway, just in a different place. Plus, I don't want to overlook something simple. So what say you stack overflow enthusiasts? How does one get back all the data of joined query using JPA?
Suppose you have a Person entity with a OneToMany association to the Contact entity.
When you get a Person from the entityManager, calling any method on its collection of contacts will lazily load the list of contacts of that person:
person.getContacts().size();
// triggers a query select * from contact c where c.personId = ?
If you want to use a single query to load a person and all its contacts, you need a fetch in the SQL query:
select p from Person p
left join fetch p.contacts
where ...
You can also mark the association itself as eager-loaded, using #OneToMany(lazy = false), but then every time a person is loaded (vie em.find() or any query), its contacts will also be loaded.
I have an application that allows for "contacts" to be made completely customized. My method of doing that is letting the administrator setup all of the fields allowed for the contact. My database is as follows:
Contacts
id
active
lastactive
created_on
Fields
id
label
FieldValues
id
fieldid
contactid
response
So the contact table only tells whether they are active and their identifier; the fields tables only holds the label of the field and identifier, and the fieldvalues table is what actually holds the data for contacts (name, address, etc.)
So this setup has worked just fine for me up until now. The client would like to be able to pull a cumulative report, but say state of all the contacts in a certain city. Effectively the data would have to look like the following
California (from fields table)
Costa Mesa - (from fields table) 5 - (counted in fieldvalues table)
Newport 2
Connecticut
Wallingford 2
Clinton 2
Berlin 5
The state field might be id 6 and the city field might be id 4. I don't know if I have just been looking at this code way to long to figure it out or what,
The SQL to create those three tables can be found at https://s3.amazonaws.com/davejlong/Contact.sql
You've got an Entity Attribute Value (EAV) model. Use the field and fieldvalue tables for searching only - the WHERE caluse. Then make life easier by keeping the full entity's data in a CLOB off the main table (e.g. Contacts.data) in a serialized format (WDDX is good for this). Read the data column out, deserialize, and work with on the server side. This is much easier than the myriad of joins you'd need to do otherwise to reproduce the fully hydrated entity from an EAV setup.