I'm trying to create the edmx file as part of an automated build process in order to ensure the code is in sync with the DB.
The emdx diagram doesn't use the complete DB so I have used EntityStoreSchemaGenerator and EntityModelSchemaGenerator in System.Data.Entity.Design in order to only include the tables, views and stored procedures needed.
I can then use the generated csdl, msl and ssdl files to create an edmx file.
The issue is that FunctionImport tags are not generated and nor are complex type tags.
These tags are generated when using the edmx designer tool.
From what I gather, the edmx designer tool uses the same generator calls (in System.Data.Entity.Design)
but seems to produce those extra tags.
Is there a way to programmatically get these additional tags auto generated preferably (although not essential) using the System.Data.Entity.Design library?
Related
I am trying to use swagger-codegen (the maven plugin) to generate my models. But I need one of my fields to be static. I was wondering if there's a property I could use in my yaml file to indicate that the field is static. Does anyone have an existing example I could look at?
I want to add a property for a document type in Umbraco. After that, I want to add content using the newly edited document type. Finally, I want to edit the property value of the content and save it into the database. I want to do this using a SQL command in SQL Server Management Studio, given that I have installed Umbraco and I can access the Umbraco database.
You shouldn't do these things directly in the database with Umbraco. In fact, part of your requirements (adding content) wouldn't display on the front end if you did it in the database, as doing so would not fire the events needed to add your new content to the site XML cache.
Ideally you should be doing this in code, using the API. You don't mention which version of Umbraco you're using, so I'll assume the latest (7). That being the case, you ca use the various service APIs to accomplish your requirements. You'd use the ContentType Service to create your new Document Type, and the Content Service to add the content of your new type.
For more information, refer to the Umbraco services reference page: here
As Tim says it's not a good idea to do this with SQL, an alternative solution is to do it with a package. An Umbraco package contains an XML document, it is also possible there to make an adjustment in the XML (if the goal is a generated change)
I have on the one hand a wsdl url/file and on the other hand a number of xsd schema files (are the latte called binding files?).
All of these describe a webservice that I would like to consume using jax-ws.
I understand I need to generate client stubs using the wsimport utility.
I have a requirement for one distinct package per xsd schema/binding file for the generated stubs files. The generated stubs for the wsdl would be located in another package.
Does that make sense?
Is this possible? If so how?
I am missing something?
edit: I don't fully understand the difference of intent between files generated against the wsdl and files generated against the xsd binding files as when using wsimport. Can someone please explain?
baleto
first thing the xjb files are used to resolve conflicts and customizing schemas.
You can create a distinct package for a XSD if it has a specfic namespace defined for it.
For example you need a package name like com.foo.healthcare.claims then you need to have a name space for the schema as http://www.foo.com/healthcare/claims.
I have a list of URL and I should loop over them every minute or so and save the last successful access time into an XML file or database. Obviously, the URL and some short description will be saved in file as well.
I'm wondering whether XML files are reliable enough or I'm better with a database? If I must go with the database option, which one?
Please advise. Thanks.
You can use XML file for this purpose.
There are lot of options for XML like XML Data Binding, TXMLDocument, XML with ClientDatasets etc.
The simplest option is XML with ClientDataSet.
This is the procedure:
Drop a ClientDataSet on the the form.
Add FieldDefs you need to the ClientDataSet.
Right click on the ClientDataSet component and click Create Dataset.
Right click again and click Save To MyBase XML Table.
You XML is ready and from now onwards you can use ClientDataSet1.LoadFromFile() and ClientDataSet1.SaveToFile() functions to load and save data.
Then you can assign ClientDataSet DataSource to the DBGrid.
I would also use a XML (or JSON) file storage. A simple way to build wrapper classes for a XML file is the XML Schema Binding Generator Wizard in Delphi Professional, or the Data Binding Wizard (in Enterprise / Architect). You only need to provide an example XML or a W3C XSD file. The wizard will create DOM based classes and binding code.
Tutorials:
Delphi XML Binding Wizard Tutorial
Delphi Programming Tutorial #39 - XML Data Binding
I would not use XML. To modify an XML file you have to rewrite it, XML is not good at random read and writes, unless you can modify it only in memory and then write it when needed. Well, every minute is not a problem, unless the XML gets very large. An XML file is reliable as much as your application is in writing it. If you need more, you should consider a database. For local access something alike SQLite or Firebird embedded could be your choice.
This may just be a yes or no type of question but here goes anyway...
From all (well most) of the examples that I've seen for using mvc, it appears that method for creating the dbml file is just drop the entire schema of the database into it and let it autogenerate all of the linq to sql goodness. It appears that you just need one of these (as you can't have duplicate tables in separate dbml files in the same project) but for some reason it would seem like there's a better way to do this...especially when dealing with a large project that has a fair number of tables.
So is this the proper way to go about creating a dbml file to use in a mvc project, just drop the entire table structure into and go to town? If not, how do you do it?
If the schema was large, I think i would be relying fully on a SQLMetal script to generate my *.dbml and backing classes. This way you can just regenerate your entire data model whenever your database gets updated. Otherwise, if a table, view, etc, gets updated in the database you don't have to delete and then re drag-and-drop that table into your visual *.dbml file.
Actually, I am not expert with SQLMetal, but I think you can even use it it to generate everything you need for Linq-toSql and not even require/generate a *.dbml file.
I'm not sure yet - its a problem I'm still working on but I think that the answer is that should it be desirable to have multiple dbml files - effectively views of your data - then you want to host the dbml files in their own projects so that you can have the similar things in multiple namespaces and not have them conflict.
This being the case the next logical step is to put your dbml files/models into their own projects by default and to learn to work with them when set up that way. This will also aid reuse of a model of database where you have more than one application interacting with that database.
There are certainly issues with separating the thing out and also with having multiple dbml files in a a single project (in terms of ensuring that extensions to the classes are implemented conistently in all instances for example) but I've got a case where its not inappropriate.
Good question, answer probably tends towards being "just one" but not in every case...
Personally I prefer to create the classes/association in the .dbml and then generate the database from that.
Just add the following class to your project
partial class MyDataContext {
partial void OnCreated() {
if (!DatabaseExists())
CreateDatabase();
}
}