Ok... I tried google and didn't get many hits. I dont want to abuse So but this is one of the best places to ask and EF isn't well documented.
My fails because the GetOriginal() returns null in UpdateCmsProductCategory. I assume that means currentCmsProductCategory is not in the ChangeSet. Ok... how do I put it in the changeset?
Here is the sequence...
I pull a CmsProductCategory down over Wcf.
I make changes.
I call the Wcf update method...
public void UpdateProductCategory(CmsProductCategory category)
{
domainservice.UpdateCmsProductCategory(category);
}
Which calls the Domain servide method...
public virtual void UpdateCmsProductCategory(CmsProductCategory currentCmsProductCategory)
{
this.Context.AttachAsModified(currentCmsProductCategory,
this.ChangeSet.GetOriginal(currentCmsProductCategory));
}
And that should work - but no, it Exceptions on me when GetOriginal() fails. I feel like I am missing a step between when the code modifies it and I pass it to Wcf.
Any hints / pointers to good documentation?
Thanks!
Your problem is probably that you lose the "context".
When you make the call to update the "this.Context" is not the same as the one you read it from.
WCF has a concept of "per call" and "per session". The "per call" is default your are therefore getting a new instance of the domain service. You may be able to solve it using per session.
Have a look at this link: http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
Also try writing a test to check that what you are doing works without transfering the data over wcf.
Related
I'm trying to figure out if FeathersJS suits my needs. I have looked at several examples and use cases. FeathersJS uses a set of request methods : find, get, create, update, patch and delete. No other methods let alone custom methods can be implemented and used, as confirmed on this other SO post..
Let's imagine this application where users can save their app settings. Careless of following method conventions, I would create an endpoint describing the action that is performed by the user. In this case, we could have, for instance: /saveSettings. Knowing there won't be any setting-finding, -creation, -updating (only some -patching) or -deleting. I might also need a /getSettings route.
My question is: can every action be reduced down to these request methods? To me, these actions are strongly bound to a specific collection/model. Sometimes, we need to create actions that are not bound to a single collection and could potentially interact with more than one collection/model.
For this example, I'm guessing it would be translated in FeathersJS with a service named Setting which would hold two methods: get() and a patch().
If that is the correct approach, it looks to me as if this solution is more server-oriented than client-oriented in the sense that we have to know, client-side, what underlying collection is going to get changed or affected. It feels like we are losing some level of freedom by not having some kind of routing between endpoints and services (like we have in vanilla ExpressJS).
Here's another example: I have a game character that can skill-up. When the user decides to skill-up a particular skill, a request is sent to the server. This endpoint can look like POST: /skillUp What would it be in FeathersJS? by implementing SkillUpService#create?
I hope you get the issue I'm trying to highlight here. Do you have some ideas to share or recommendations on how to organize the API in this particular framework?
I'm not an expert of featherJs, but if you build your database and models with a good logic,
these methods are all you need :
for the settings example, saveSettings corresponds to setting.patch({options}) so to the route settings/:id?options (method PATCH) since the user already has some default settings (created whith the user). getSetting would correspond to setting.find(query)
To create the user AND the settings, I guess you have a method to call setting.create({defaultOptions}) when the user CREATE route is called. This would be the right way.
for the skillUp route, depends on the conception of your database, but I guess it would be something like a table that gives you the level/skills/character, so you need a service for this specific table and to call skillLevel.patch({character, level})
In addition to the correct answer that #gui3 has already given, it is probably worth pointing out that Feathers is intentionally restricting in order to help you create RESTful APIs which focus on resources (data) and a known set of methods you can execute on them.
Aside from the answer you linked, this is also explained in more detail in the FAQ and an introduction to REST API design and why Feathers does what it does can be found in this article: Design patterns for modern web APIs. These are best practises that helped scale the internet (specifically the HTTP protocol) to what it is today and can work really well for creating APIs. If you still want to use the routes you are suggesting (which a not RESTful) then Feathers is not the right tool for the job.
One strategy you may want to consider is using a request parameter in a POST body such as { "action": "type" } and use a switch statement to conditionally perform the desired action. An example of this strategy is discussed in this tutorial.
I am looking for a way to intercept Session.SaveChanges() so that I may execute some extra work using the same session instance (this is handy in some cases).
Edit: The point about re-using the session is that I have more work that needs to run in the same transaction.
I am already aware of (and make use of) IDocumentStoreListener - but this interface doesn't help because it does not give me access to the current session.
I can't find anything in RavenDb documentation about a way to intercept the call to SaveChanges and get a handle on the current session. Does anyone know of a way?
Open a new session it's free (in terms of performance), I think that IDocumentStoreListener has been thought for what you're looking for. I don't know other that works as you say.
implementing
void AfterStore(string key, object entityInstance, RavenJObject metadata);
you have all the information about the stored entity and then you can do what you need
I have an issue in a new devkit Project where the following #ValidateConnection method is failing to be called (but my #processor methods are called fine when requested in the flows)
#ValidateConnection
public boolean isConnected() {
return isConnected;
}
I thought that the above should be called to check whether to call the #Connect method.
I think it is because I am using a non default category (Components) for the connector
#Category(name = "org.mule.tooling.category.core", description = "Components")
And the resulting Behavoir is different to what I am used to with DevKit in Cloud connector mode.
I guess I will need to do checks in each #processor for now to see if the initialization logic is done, as there doesn't seem to be an easy way to run a one time config.
EDIT_________________
I actually tried porting it back to a cloud connector #cat and the same behaviour, maybe its an issue with devkit -DarchetypeVersion=3.4.0, I used 3.2.x somthing before and things worked a bit better
The #ValidateConnection annotated method in the #Connector is called at the end of the makeObject() method of the generated *ConnectionFactory class. If you look for references of who is calling your isConnected() you should be able to confirm this.
So no, you should not need to perform the checks, it should be done automatically for you.
There must be something else missing... do you have a #ConnectionIdentifier annotated method?
PS. #Category annotation is purely for cosmetic purposes in Studio.
I get the following error within Magento CE 1.6.1.0
Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/dev/env/var/www/user/dev/wdcastaging/lib/Zend/Controller/Response/Abstract.php:586) in /home/dev/env/var/www/user/dev/wdcastaging/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 119
when accessing /api/soap/?wsdl
Apparently, a session_start() is being attempted after the entire contents of the WSDL file have already been output, resulting in the error.
Why is magento attempting to start a session after outputting all the datums? I'm glad you asked. So it looks like controller_front_send_response_after is being hooked by Mage_Persistent in order to call synchronizePersistentInfo(), which in turn ends up getting that session_start() to fire.
The interesting thing is that this wasn't always happening, initially the WSDL loaded just fine for me, initially I racked my brains to try and see what customization may have been made to our install to cause this, but the tracing I've done seems to indicate that this is all happening entirely inside of core.
We have also experienced a tiny bit of (completely unrelated) strangeness with Mage_Persistent which makes me a little more willing to throw my hands up at this point and SO it.
I've done a bit of searching on SO and have found some questions related to the whole "headers already sent" thing in general, but not this specific case.
Any thoughts?
Oh, and the temporary workaround I have in place is simply disabling Mage_Persistent via the persistent/options/enable config data. I also did a little bit of digging as to whether it might be possible to observe an event in order to disable this module only for the WSDL controller (since that seems to be the only one having problems), but it looks like that module relies exclusively on this config flag to determine it's enabled status.
UPDATE: Bug has been reported: http://www.magentocommerce.com/bug-tracking/issue?issue=13370
I'd report this is a bug to the Magento team. The Magento API controllers all route through standard Magento action controller objects, and all these objects inherit from the Mage_Api_Controller_Action class. This class has a preDispatch method
class Mage_Api_Controller_Action extends Mage_Core_Controller_Front_Action
{
public function preDispatch()
{
$this->getLayout()->setArea('adminhtml');
Mage::app()->setCurrentStore('admin');
$this->setFlag('', self::FLAG_NO_START_SESSION, 1); // Do not start standart session
parent::preDispatch();
return $this;
}
//...
}
which includes setting a flag to ensure normal session handling doesn't start for API methods.
$this->setFlag('', self::FLAG_NO_START_SESSION, 1);
So, it sounds like there's code in synchronizePersistentInf that assumes the existence of a session object, and when it uses it the session is initialized, resulting in the error you've seen. Normally, this isn't a problem as every other controller has initialized a session at this point, but the API controllers explicitly turns it off.
As far as fixes go, your best bet (and probably the quick answer you'll get from Magento support) will be to disable the persistant cart feature for the default configuration setting, but then enable it for specific stores that need it. This will let carts
Coming up with a fix on your own is going to be uncharted territory, and I can't think of a way to do it that isn't terribly hacky/unstable. The most straight forward way would be a class rewrite on the synchronizePersistentInf that calls it's parent method unless you've detected this is an API request.
This answer is not meant to replace the existing answer. But I wanted to drop some code in here in case someone runs into this issue, and comments don't really allow for code formatting.
I went with a simple local code pool override of Mage_Persistent_Model_Observer_Session to exit out of the function for any URL routes that are within /api/*
Not expecting this fix to need to be very long-lived or upgrade-friendly, b/c I'm expecting them to fix this in the next release or so.
public function synchronizePersistentInfo(Varien_Event_Observer $observer)
{
...
if ($request->getRouteName() == 'api') {
return;
}
...
}
I have a problem with WCF. My testing code is pretty simple.
I call a service layer method on my server from my silverlight application and print the result in a textbox.
Everything of this is surrounded by try-catch.
When my service layer method simply returns a constantly defined string there seems to be no problems - however as soon as it calls a more complex method it fails.
While debugging it does not even reach the complex model method; it fails before that inside some auto-generated code from microsoft:
/WuSIQ.jpg
As the error message "NotFound" is not exactly the most helpful or specific you can imagine my trouble googling for hints.
I thought maybe the auto-generated code could only send simple data so I made a temporary string and returned that, but this did not help.
I have already: a client access policy, a service reference added, removed duplicate reference in ServiceReferences.ClientConfig and a ServiceLayer.svc.cs.
I am debugging by running from the main window and my breakpoints are picked up.
Anyone?
I had some errors in the server side method that were quickly found after debugging was fixed.
I fixed this, as I said in comments, setting the project to have "Multiple Startup Projects".
Whenever I had troubles with updating the WCF service methods one of these usually solved it all:
1 Delete all bin and obj folders (specifically selecting re-build might do the same).
2 The servicelayer will not succesfully auto-update (but will work!) unless this:
[ServiceContract(Namespace = "")]
... is set to this:
[ServiceContract(Namespace = "YourServiceLayerName")]
3 Right clicking on the servicereference and selecting "update...".
Sometimes it would stop debugging again, but a forced full re-build would return it to normal.
I hope this helps someone.