JSON proposes a way to reference an element in the same, or a different, file: https://json-spec.readthedocs.io/reference.html
How to make property_tree::read_json to properly handle these references ?
Related
I'm reading this page (I'm not using Amazon, just reading for golang education)
https://aws.amazon.com/blogs/developer/mocking-out-then-aws-sdk-for-go-for-unit-testing/
When I try it for myself, I get type errors.
type Queue struct {
Client ThirdPartyStruct
URL string
}
type mockedReceiveMsgs struct {
ThirdPartyStruct
Resp ValueIWantToMock
}
q := Queue{Client: mockedReceiveMsgs{}}
When I try to do the exact same thing, I get
cannot use mocked literal (type mockedReceiveMsgs) as type ThirdPartyStruct in field value
I feel like I'm copying the Amazon tutorial exactly. How come in there code, mockedReceiveMsgs can be used in place of ThirdPartyStruct?
The issue is not with mocking but with the fact that Queue structure includes ThirdPartyStruct by value (as a substructure), not as a pointer. And so does mockedReceiveMsgs. It just so happened that in Queue structure this substructure can be accessed by Client name and in mockedReceiveMsgs it is supposedly "anonymous" (but actually can be referred by ThirdPartyStruct name if required).
So, q := Queue{Client: mockedReceiveMsgs{}} actually tries to copy over mockedReceiveMsgs into Client and it obviously fails as it has extra bits, which don't fit into ThirdPartyStruct. You can make it compile by changing it to q := Queue{Client: mockedReceiveMsgs{}.ThirdPartyStruct} though I doubt this is what you want.
Note, that if you change Client ThirdPartyStruct to Client interface{} (in your original example) then it will compile as well. And this is most likely what you want. And it will also work with any interface type. Which is what #tkausl most likely was pointing out. The only tricky bit is pointer semantics vs value semantics when you're implementing your interface. It does back fire sometimes. See a quick example here
If ThirdPartyStruct is, as it's name implies, a struct type as opposed to an interface type, then you cannot mock it, it is just not possible in Go. If you read your example article carefully and follow the link that shows the definition of SQSAPI you'll see that it is an interface type.
type SQSAPIinterface{
To make your code "mockable" you need to use an interface type for the Client field. Here's an example that is more true to the aws one: https://play.golang.org/p/puhhgmFCUC4
I am currently saving my object graph in xml file with boost serialization. The library is great, it automatically restores the objects and all member pointers and references.
Problem :
I need to have random access to the data ( read just one object, or delete just one object ). With boost serialization the scenario is like this :
--load all objects from file
-- use and modify objects
-- write all objects to archive again
The drawback with this is if only one object changed , I want to write to the archive only that object, and not the entire object graph which is huge.
So I am looking for library which support storing all objects to database, and which also supports boost and stl types. Currently I am using these boost types:
boost multi-index
Smart Ptr ( shared_ptr,weak_ptr,scoped_ptr)
optional,variant
Anyone knows such library or something close to it, or have idea how to go for resolving this problem?
Have you tried ODB? http://www.codesynthesis.com/products/odb/
It is very complicate to do such a thing. Since C++ (the runtime environment) does not know anything about itself you have to code it on your own. My advice is to split the graph onto different files and to update only the files that are needed (this means that you have to control serialization on your own, not using boost lib).
Maybe Wt::Dbo? By adding a single template function to your classes, Dbo maps them to an SQL database.
So I've been attempting to create some classes around the xerces XML library so I can 'hide' it from the rest of my project the underlying xml library stays independent from the rest of my project.
This was supposed to be a fairly easy task, however it seems entirely impossible to hide a library from the rest of a project by writing some classes around it.
Have I got the wrong approach or is my 'wrapper' idea completely silly?
I end up with something like this:
DOMElement* root(); //in my 'wrapper' class, however this DOMElement is part of the xerces library, at this point my 'wrapper' is broken. Now I have to use the xerces library everywhere I want to use this function.
Where is my thinking gone wrong?
I would recommend avoiding the wrapper in the first stage. Just make sure that the layers and their borders are clear, i.e. the network layer takes care of serializing/deserializing the XML, and from there on you only use your internal types. If you do this, and at a later stage you need to replace xerces with any other library, just replace the serialization layer. That is, instead of wrapping each XML object, just wrap the overall operation: serialize/deserialize.
Writing your own abstract interface for a library is not a silly idea IF you have plan to change or to have the possibility to change the library you are using.
You should not rely on your library object to implement your wrapper interface. Implement your own structure and your own function interface. It will ease a lot of work when you will want to change how xml is implemented (eg: change library).
One example of implementation:
class XmlElement
{
private:
DOMElement element; // point to the element of your library
public:
// Here you define how its public interface.
// There should be enough method/parameter to interact
// with any xml interface you will use in the future
XmlElement getSubElement(param)
{
// Create the Xmlelement
// Set the DOMElement wanted
// return it
}
}
In your program you will see:
void function()
{
XmlElement root();
root.getSubElement("value"); // for example
}
Like that no DOMElement or their function appear in the project.
As I mentioned in my comments, I would take a slightly different approach. I would not want my codebase to be dependent on the particular messaging format (xml) that I am using (what if for example you decide to change the xml to something else later?) Instead I would work with a well defined object model and have a simple encoder/decoder to handle the conversion to XML string and vice versa. This encode/decoder would then be the bit that I would replace if the underlying wire format changed.
The decoder would take in the data read from the socket, and produce a suitable object (with nested objects to represent the request) and the decoder would take a similar object and generate the XML from it. If performance is not a primary concern, I would use a library such as TinyXML which is quite lightweight - heck, you can strip that down even further and make it more light weight...
I'm having a bit of difficulty passing a reference type between webservices.
My set up is as follows.
I have a console application that references two web-services:
WebServiceOne
WebServiceTwo
WebServiceOne declares the details of a class I am using in my console application...let's call it MyClass.
My console application calls WebServiceOne to retrieve a list of MyClass.
It then sends each MyClass off to WebServiceTwo for processing.
Within in the project that holds WebServiceTwo, there is a reference to WebServiceOne so that I can have the declaration of MyClass.
The trouble I'm having is that, when I compile, it can't seem to determine that the MyClass passed from the console application is the same as the MyClass declared in WebServiceOne referenced in WebServiceTwo.
I basically get an error saying Console.WebServiceOne.MyClass is not the same as MyProject.WebServiceOne.MyClass.
Does anyone know if doing this is possible? Perhaps I'm referencing WebServiceOne incorrectly? Any idea what I might be doing wrong?
My only other option is to pass each of the properties of the reference type directly to WebServiceTwo as value types...but I'd like to avoid that since I'd end up passing 10-15 parameters.
Any help would be appreciated!
I had a chat with one of the more senior guys at my work and they proposed the following solution that has worked out well for me.
The solution was to use a Data Transfer Object and remove the reference to WebServiceOne in WebServiceTwo.
Basically, in WebServiceTwo I defined a representation of all the value type fields needed as BenefitDTO. This effectively allows me to package up all the fields into one object so I don't have to pass each of them as parameters in a method.
So for the moment, that seems to be the best solution...since it works and achieves my goal.
It's likely that I didn't explain my question very well...which explains why no one was able to help...
But thanks anyway! :-)
Move the types to a separate assembly and ensure that both services use this. In the web service reference there is probably some autogenerated code called Reference.cs. Alter this to use your types.
Edit: To reflect comments
In that case take the reference.cs from that web service you cannot control use it as the shared type.
Your error message explains the problem. The proxy class on the client side is not the same type as the original class on the server side, and never will be. Whether it's a reference type or a value type is irrelevant to how it works.
I don't quite understand what your exact problem is, but here are a few guesses:
If you are trying to compare two objects for equality, then you will have to write your own compare function that compares the values of each significant property/field in turn.
If you are trying to copy an object from one service to the other, then you will have to write your own copy function that copies the values of each significant property/field in turn.
If you were using WCF, you would have the option of bypassing all this and just sharing one class definition between the client and both services.
I wrote a file parser for a game I'm writing to make it easy for myself to change various aspects of the game (things like the character/stage/collision data). For example, I might have a character class like this:
class Character
{
public:
int x, y; // Character's location
Character* teammate;
}
I set up my parser to read in from a file the data structure with syntax similar to C++
Character Sidekick
{
X = 12
Y = 0
}
Character AwesomeDude
{
X = 10
Y = 50
Teammate = Sidekick
}
This will create two data structures and put them in a map<std::string, Character*>, where the key string is whatever name I gave it (in this case Sidekick and AwesomeDude). When my parser sees a pointer to a class, like the teammate pointer, it's smart enough to look up in the map to fetch the pointer to that data structure. The problem is that I can't declare Sidekick's teammate to be AwesomeDude because it hasn't been placed into the Character map yet.
I'm trying to find the best way to solve this so that I can have my data structures reference objects that haven't yet been added to the map. The two easiest solutions that I can think of are (a) add the ability to forward declare data structures or (b) have the parser read through the file twice, once to populate the map with pointers to empty data structures and a second time to go through and fill them in.
The problem with (a) is that I also can decide which constructor to call on a class, and if I forward declare something I'd have to have the constructor be apart from the rest of the data, which could be confusing. The problem with (b) is that I might want to declare Sidekick and AwesomeDude in their own files. I'd have to make my parser be able to take a list of files to read rather than just one at a time (this isn't so bad I guess, although sometimes I might want to get a list of files to read from a file). (b) also has the drawback of not being able to use data structures declared later in the constructor itself, but I don't think that's a huge deal.
Which way sounds like a better approach? Is there a third option I haven't thought of? It seems like there ought to be some clever solution to this with pointer references or binding or something... :-/ I suppose this is somewhat subjective based on what features I want to give myself, but any input is welcome.
When you encounter the reference the first time, simply store it as a reference. Then, you can put the character, or the reference, or whatever on a list of "references that need to be resolved later".
When the file is done, run through those that have references and resolve them.
Well, you asked for a third option. You don't have to use XML, but if you follow the following structure, it would be very simple to use a SAX parser to build your data structure.
At any rate, instead of referencing a teammate, each character references a team (Blue team in this case). This will decouple the circular reference issue. Just make sure you list the teams before the characters.
<team>Blue</team>
<character>
<name>Sidekick</name>
<X>12</X>
<Y>0</Y>
<teamref>Blue</teamref>
</character>
<character>
<name>Sidekick</name>
<X>10</X>
<Y>50</Y>
<teamref>Blue</teamref>
</character>
Personally, I'd go with b). Splitting your code into Parser and Validator classes, both operating on the same data structure. The Parser will read and parse a file, filling the data structure and storing any object references as their textual names, leaving the real pointer null in your structure for now.
When you are finished loading the files, use the Validator class to validate and resolve any references, filling in the "real" pointers. You will want to consider how to structure your data to make these lookups nice and fast.
Will said exactly what I was about to write. Just keep a list or something with the unsolved references.
And don't forget to throw an error if there are unsolved references once you finish reading the file =P
Instead of storing Character object in your map, store a proxy for Character. The proxy will than contain a pointer to the actual Character object when the object is loaded. The type of Character::teammate will be changed to this proxy type. When you read in a reference that is not already in your map, you create a proxy and use the proxy. When you load an character which you already have an empty proxy in the map, populate it with your newly loaded character. You may also want to add a counter to keep track of how many empty proxy you have in the map so you know when all referenced characters have been loaded.
Another layer of indirection....it always make programming easier and slower.
One option would be to reverse the obligation. The Map is responsible for filling in the reference
template<T> class SymbolMap // I never could rememeber C++ template syntax
{
...
/// fill in target with thing name
/// if no name yet, add it to the list of thing that will be name
void Set(T& target, std::string name);
/// define name as target
/// go back and fill in anything that needs to be name
void Define(T target, std::string name);
/// make sure everything is resolved
~SymbolMap()
}
that won't interact well with value/moving semantics but I suspect that not much will.