In my Model.hs I can successfully use the data types that correspond to my data tables that I describe in config/models file.
I would like to use these types in my other files, for example, in Foundation.hs.
Is there a module that I need to import or a function to call from the file where I need to use the types?
I do not know why my first answer was deleted. Again, these types are visible in other files without importing anything. I posted the question too soon.
Related
We have a common variables in our infrastructure on AWS, planned to be used by several modules. For example subnet ids, vpc id and so on.
To avoid duplication those variable in each module in *.tfvars files. Is that possible make them available from any terraform modules? While modules itself can be isolated from each other.
I think about kind of core module, which can be imported where that common variables needs. But in doubts that module is a right way to do that, as modules intended to have only resources in them, but we need expose only variables. Is it right way to use modules to share variables? Or how you guys cope with this problem? Think it's common or it's bad approach in terraform?)
Thanks.
If you have a set of expressions (including hard-coded literal values) that you want to reuse then it is valid to write a module which only contains input variable declarations, local values, and output values as a way to model that.
The simplest form of this would be a module that only contains output blocks whose values are hard-coded literal values, like this:
output "example" {
value = "result"
}
The official module hashicorp/subnets/cidr is an example of that: it doesn't declare any resources of its own, and instead it just encapsulates some logic for calculating a set of subnets based on some input variables.
This is a special case of Data-only Modules where the data comes from inside the module itself, rather than from data sources. A nice thing about modelling shared data in this way is that if you later decide to calculate those results automatically based on data sources then you'll be able to do so, while keeping the details encapsulated. For example, if you define a module which takes an environment name as an input variable and returns derived settings about that environment, the module could contain local logic to calculate those results today but could later determine some of those settings by fetching them from a prescribed remote location, such as AWS SSM Parameter store, if the need arises.
I'm checking out Flatbuffers for implementing a communication protocol. When a message is received, it may in my case contain a number of different tables. If I understand correctly, the way to achieve this in Flatbuffers is to use a "root" table that has each possible different table in a union.
In my case, I will already know the incoming type (type is part of the header) => I do not necessarily need to be able to place each type inside a single table. However, it does not seem to be possible to mark multiple tables as "root" types. This means that if I have defined the tables Foo and Bar that I can only get either a GetFoo() or a GetBar() method for deserialization, but not both.
I am assuming that it would also be possible to split the definitions across different schema files, but since they would share some subclasses I would also need a shared schema file for the common definitions. This seems to be a bit more complicated than necessary for simple cases.
Is there another way of being able to deserialize multiple different types with Flatbuffers?
Yes, you can do this. Note that the generated GetMyType() is just short for the templated GetRootAs<MyType> which you can use with any type.
It's possible combinate augeas & template?. The objective its a static part of test inside a file an another variable with the augeas.
I'm reading the documentation and examples but I think its not possible.
If its possible, can you put an example?
thanks
If you manage a file with the file type, you need to manage it entirely and you cannot manage parts of it with another type, such as augeas. In order to manage files by parts, you may want to consider using one of the concat modules instead (Puppet Labs' or Onyxpoint's)
I'm writing a python script to generate C++ classes used for database access and they use RogueWave types for data transfer. I have a few template classes I'm looking at to outline how the generated classes should look. When implementing a method for transferring several tuples in one operation, columns are wrapped in RWDBTbuffer, RWDBVector and RWDBDecimalVector.
My problem is, I can't see a direct correlation between the data type that is being wrapped (int, long, RWDateTime, RWDecimalPortable) and the container it is being placed in. It seems to me that I can just put everything in a RWDBTBuffer. What is the advantage of using RWDBDecimalVector over RWDBTBuffer for numeric types, and should RWDBVector ever be used?
in terms of data that they both store there isn't any different.
the main different is that you can shift RWDBVector into RWDBReader and then you can read the data into it.
I have a query, I have set of flat files ( say file1, file2 etc) containing column names and native data types. ( how values are stored and can be read in c++ is elementary)
eg. flat file file1 may have data like
col1_name=id, col1_type=integer, col2_name=Name, col2_type=string and so on.
So for each flat file I need to create C++ data structure ( i.e 1 flat file = 1 data structure) where the member variable name is same name as column name and its data type will be of C++ native data type like int, float, string etc. according to column type in flat file.
from above eg: my flat file 1 should give me below declaration
class file1{
int id;
string Name;
};
Is there a way I can write code in C++, where binary once created will read the flat file and create data structure based on the file ( class name will be same as flat file name). All the classes created using these flat files will have common functionality of getter and setter member functions.
Do let me know if you have done something similar earlier or have any idea for this.
No, not easily (see the other answers for reasons why not).
I would suggest having a look at Python instead for this kind of problem. Python's type system combined with its ethos of using try/except lends itself more easily to the challenge of parsing data.
If you really must use C++, then you might find a solution using the dynamic properties feature of Qt's QObject class, combined with the QVariant class. Although this would do what you want, I would add a warning that this is getting kind of heavy-weight and may over-complicate your task.
No, not directly. C++ is a compiled language. The code for every class is created by the compiler.
You would need a two-step process. First, write a program that reads those files and translates them into a .cpp file. Second, pass those .cpp files to a compiler.
C++ classes are pure compile-time concepts and have no meaning at runtime, so they cannot be created. However, you could just go with
std::vector<std::string> fields;
and parse as necessary in your accessor functions.
No, but from what I can tell, you have to be able to store the names of multiple columns. What you can do is have a member variable map or unordered_map which you can index with a string - the name of the column - and get some data (like a column object or something) back. That way you can do
obj.Columns["Name"]
I'm not sure there's a design pattern to this, but if your list of possible type names is finite, and known at compile time, can't you declare all those classes in your program before running, and then just instantiate them based on the data in the files?
What you actually want is a field whose exact nature varies at runtime.
There are several approaches, including Boost.Any, but because of the static nature of C++ type system only 2 are really recommended, and both require to have beforehand an idea of all the possible data types that may be required.
The first approach is typical:
Object base type
Int, String, Date whatever derived types
and the use of polymorphism.
The second requires a bit of Boost magic: boost::variant<int, std::string, date>.
Once you have the "variant" part covered, you need to implement visitation to distinguish between the different possible types. Typical visitors for the traditional object-oriented approach or simply boost::static_visitor<> and boost::apply_visitor combinations for the boost approach.
It's fairly straightforward.