I have a table that has a column with SQL_Variant type and some other columns with types like int, bigint,...
When I add this table to edmx file it adds all columns but the SQL_Variant typed column.
Is there a bug or I have to do something to add that column?
The entity framework doesn't support sql_variant. If you have to use that type in your code, you've to use another o/r mapper.
There is a solution for read-only access.
Related
Since Firebird 3, I can't modify a column type.
Before I use this kind of update:
update RDB$RELATION_FIELDS set
RDB$FIELD_SOURCE = 'MYTEXT'
where (RDB$FIELD_NAME = 'JXML') and
(RDB$RELATION_NAME = 'XMLTABLE')
because I get ISC error 335545030 ("UPDATE operation is not allowed for system table RDB$RELATION_FIELDS").
Maybe there is another way in Firebird 3?
Firebird 3 no longer allows direct updates to the system tables, as that was a way to potentially corrupt a database. See also System Tables are Now Read-only in the release notes. You will need to use DDL statements to do the modification.
It looks like you want to change the data type of a column to a domain. You will need to use alter table ... alter column ... for that. Specifically you will need to do:
alter table XMLTABLE
alter column JXML type MYTEXT;
This does come with some restrictions:
Changing the Data Type of a Column: the TYPE Keyword
The keyword TYPE changes the data type of an existing column to
another, allowable type. A type change that might result in data loss
will be disallowed. As an example, the number of characters in the new
type for a CHAR or VARCHAR column cannot be smaller than the existing
specification for it.
If the column was declared as an array, no change to its type or its
number of dimensions is permitted.
The data type of a column that is involved in a foreign key, primary
key or unique constraint cannot be changed at all.
This statement has been available since before Firebird 1 (InterBase 6.0).
Firebird 2.5 manual, chapter Data Definition (DDL) Statement, section TABLE:
ALTER TABLE tabname ALTER COLUMN colname TYPE typename
When I add a column in the database, under what conditions do I need to update my EDMX?
To elaborate:
I know if I add a non-nullable field, I need to update the model if I want to write to the database. What if just I want to read?
What if it's a nullable field? Can I both read and write?
What if I were to change the primary key to the new column but the edmx still has the old column as primary?
1) If you want to port an old database, you need to make sure that every table in your database must have a primary key. This is the only requirement for creating the EDMX.
2) If you've added a column in a table at database side, and have not updated edmx, then you'll simply not be able to use that column though EntityFramework.
If you create a non nullable column with no default value, the insert operation will fail with exception "Cannot insert null into column , statement terminated". And the you'll not be able to read values of that column using entityframeowrk, unless you update the edmx.
3) If you've changed the primary key of any table at database side, and if the edmx is not aware of that, your application might create a runtime exception when performing operations with that table.
Remember, Entity Framework creates SQL queries depending upon its knowledge of database(which is defined in EDMX). So if EDMX is incorrect, the resulting SQL queries so generated might lead to problems at runtime.
I am using EF 5 and SQL Server 2005, Model First (sort of).
By sort of, I mean that I typically build my schema in the SQL Server designer, but import the schema into EF so I have a visual view. There is often round-tripping.
However, I noticed that when I try to generate the DB schema based on the EF model, it skips all of the NEWID() default values that I have assigned as default values to my Guid IDs, but it doesn't skip the identity fields of type int.
I found this post explaining the reasoning for this:
Entity Framework 4 and Default Values
However, it doesn't answer my question: How do I get Entity Framework to generate a SQL DDL database schema with default values of NEWID() for my uniqueidentifier types?
NOTE:
I don't care about how to set them from the POCO entities and so forth (there are plenty of posts describing that) - my concern is getting the SQL DDL generated right so I can seed the database without worrying about these values going missing.
Using Entity Framework Migrations, you can use the GUID column builder and its DefaultValueSql parameter. The value of that parameter can be the string "NEWID()". This should take care of proper DDL generation.
Next you should declare these properties as database-generated using attributes or the fluent model builder, so that EF ignores the values set in your POCOs (which will be null for new objects).
In Zend Framework you can override table setup methods as explained here:
http://framework.zend.com/manual/en/zend.db.table.html#zend.db.table.defining.setup
My question is what is the use of this? Under what circumstances would this be used?
It seems pointless to me because why would you want to change the primarykey value or tablename of your class to something other than what they actually are?
You might want to use the same Zend_Db_Table class with different scenarios. In my case, I needed to use the same table structure across different schemas and table names for a project. So, I could use the same class to access, for instance:
In schema db1:
table tableA
table tableB
...
In schema db2:
table tableC
table tableD
...
(All tables having the same structure, but different names).
Actually, this flexibility was the main reason why I chose to use Zend Framework for this project.
Hope that helps,
I am using JOINED inheritance strategy with EclipseLink JPA implementation. I have noticed that EclipseLink is adding discriminator column, named by default DTYPE, to the database schema. I understand, that discriminator is needed for one table inheritance strategy, but why for JOINED strategy?
EclipseLink needs this column because I've got errors after removing it. Is this column added for performance reasons, etc? I am not particularly happy about that since from the point of view of database schema this column is just unnecessary clutter.
Hibernate based JPA does not do anything similar.
From Joined Table Inheritance:
In the joined table inheritance, each
class shares data from the root table.
In addition, each subclass defines its
own table that adds its extended
state. The following example shows two
tables, PROJECT and L_PROJECT, as well
as two classes, Project and
LargeProject:
...
The discriminator column is what determines the type and thus what joined table to use so you need a discriminator column in the parent table.