Is it possible for Breeze to access a third party API that does not have a "BreezeController" nor supports OData?
"BreezeController" is simply a .NET attribute that helps .NET WebApi provide support for query filtering and ordering via OData "syntax" and well as json serialization support for entity graphs and type identity. Type identity is important so that breeze can track the entities within its entityManager and merge the results of queries and update relation properties. OData itself is never required.
If you don't want the ability for the client to add filtering and ordering instructions to the server, you can write your own attribute that simply provides the json serialization support. The json serialization consists simply of configuring the json.net formatter that web api is already using.
The source for the BreezeControllerAttribute may be found in the Breeze.WebApi project and is really pretty short. Just create your own 'FooControllerAttribute' by copying the 'BreezeControllerAttribute' and remove the IFilterProvider code.
On the other hand, the query and filtering support won't hurt anything and this logic isn't even applied unless you use the EntityQuery 'where' 'orderBy' 'select' or 'expand' methods, so unless you want to explicitly remove this ability there is no need to not use the 'breezeControllerAttribute'
Related
Can I use oData with PetaPoco also? I have a requirement where I need to filter the records by passing more than one input parameters. The method will be a WebAPI method.
I got the answer, At the time exploring this link, I found this quote "Web API OData does not require EF. Use any data-access layer that can translate database entities into models."
It means PetaPoco should also support OData.
PetaPoco maintainer here.
No PetaPoco doesn't support OData and most likely never will.
The reason why is the mapping to and from OData for all supported DBs would be a too much work.
I have a business requirement where I need to expose set of custom properties defined by user and since this is user configuration, I cannot go away by creating classes. Therefore I need to opt for open types feature in Odata.
Q1. Is there any sample implementation out there on how I can persist the data to database and also support the querying capabilities on open types?
Q2. One issue I noticed is currently client library is not correctly handling open types and can only be achieved by partial classes that means user has to know the custom properties up front so that they can hand craft partial classes which is not what I want to do. Instead better approach would have been to support open types on client side by dynamic properties. Any pointers on how the client side experience can be optimized.
About query capabilities on open types, order and filter is supported in v5.5(will be released by the end of this month), query the value of dynamic properties, you can follow this pull request, part of this is in master branch now.
About persist the data to database, I think you can consider non-relational database, which can be a good choice for your open type data.
About Q2, achieve by dynamic properties is not implement in client library, maybe you can open an issue in github for us.
We are working on an SPA which uses Durandal + Breeze, we have used DTOs for data transfer, is there a way in Breeze through which we can make some of the properties of objects as Observable while keeping the rest as plain Javascript properties.
Please help.
Not easily, but depending on your willingness to look at the breeze source, you could take a look at the JsonResultsAdapter and the "ko" (knockout) model library implementation. Together these two control how entities and projections get materialized.
Im new to breeze js, I understand that breeze has it's own query language related to OData
But I am trying to get breeze js working with a custom query language, as an example FIQL is
one of the form to make queries to backend, can we get breeze run with this type of query language.
Overview of FIQL :-
http://jaxenter.com/tutorial-smarter-search-with-fiql-and-apache-cxf-46876.html
(this is not a technical answer, at the very most it's an advice)
As mentionned from their website documentation :
Today, out of the box, the Breeze product ships with adapters for the
ASP.NET Web API and for OData. It also ships with .NET components that
interface with the Entity Framework and that generate Breeze metadata
from an Entity Framework model; that EF model could be developed code
first or database first. The Breeze client is in no way limited to
these technologies; they are merely the first backend components
available; we’d be thrilled to help you adapt Breeze to your preferred
server stack.
First question is whether
1) you want breeze to actually create FICL queries on the client and send them to a FICL service. This involves translating a client side breeze EntityQuery into FICL url syntax. If so you would need to create a new a 'uriBuilder' adapter.
2) you want to translate a breeze query already sent to your service into FIQL syntax on the server so that you can further refine the query and then send it on to your FICL service. If so you would need to create a breeze DataService endpoint.
Both of these are certainly possible.
If you are looking at the 1st option, take a look at the 'b000_uriBuilder.xxx' files in the breeze GitHub repo under the 'src' directory. There should be two 'uriBuilder.xxx' files, one which translates an EntityQuery into OData syntax and another that translates the EntityQuery into a new 'json' query syntax. There is also additional information on this 2nd syntax here:
http://www.getbreezenow.com/documentation/query-using-json
Both of these 'uriBuilder's make use an internal 'visitor' framework that we have not yet documented but should be reasonably understandable by looking at the source.
If you are looking at the 2nd option, I would recommend looking at the link mentioned above and then taking a look at the 'breeze.node.js' repo and the 'breeze-sequelize' subdir within it. In this repo we take a serialized server side breeze EntityQuery and translate it into a 'Node' Sequelize query that we can apply to a variety of backends.
Another option is to contact our professional services arm, at breeze#ideablade.com and ask them to assist in building the adapters for you or to ask for more detailed technical help.
I am saving a complex object graph from breeze, and I get the following error from the server:
Error: CROSS APPLY is not supported by Oracle
We are using an Oracle database using Devart provider. From my research, it seems that the only solution to this problem is to avoid certain linq query expressions. These threads provide further context:
http://forums.devart.com/viewtopic.php?t=18849
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/ae826dd9-1bab-4f64-a7ee-f082a2177346/
The last thread linked is particularly disheartening, as this appears to be a Microsoft-related EF issue on which they have gone dark on for quite some time.
Since the only remedy for this appears to be avoiding specific linq operators/expressions, I must ask if there is any way to use breeze and avoid these offending linq expressions? If not, I am lead to conclude that breeze is currently limited only to relational databases that are fully-supported by EF, which from the my research is effectively only MS SQL.
Hoping I am wrong,
Mathias
If you want to use Breeze's EFContextProvider then you are limited to using an EF backend. However you do some other options. The first is that you can pass your own parameters into your controller methods, ( see the EntityQuery.withParameters method). This may allow you to rewrite your expression on the server to avoid EF expressions that cannot be tranlated properly for Oracle.
In addition, you can use Breeze with your own custom context provider or you can take over the server side completely. The first is a good approach if you are talking to another .NET backend, the second is appropriate when you are talking to an arbitrary non .NET backend.
We are planning on releasing an NHibernate backend to breeze as well as a Node-MongoDb backend within the next few weeks to illustrate both of these.