How to define schema for some columns and infer schema for the rest? Is there a way to have partial schema definitions?
Say I have columns a, b, c; I want to define schema for just a and infer for b and c. Additionally, I'm defining schema while reading.
Related
I am looking to create a union all on tables with same names in different schema.
Is there a way to do this in redshift other than a brute force method of naming individual tables and columns in the union all statement.
example:
schema z table a,
schema y table a,
schema x table a
schema z table b,
schema y table b
schema y table c,
schema x table c
tables a columns - d, e, f,g , h
table b columns - d,e,g,h,i
table c columns - d,e,f
I'd go with writing a Lambda function (or just code on your computer) to inspect the system tables for the existence of the tables in question and then find the columns of each table. Then this code would compose the SQL.
You could also likely do this in a stored procedure but this is likely more work to get running. If you need many people to be able to use from inside the DB then it is worth the effort otherwise I'd go simple.
I have a problem here about postgresql. I have defined an enum type abc in schema X. Now I want to create a table having a column with datatype abc in schema Y. Is it possible to do such a thing? If yes how?
You need to qualify the schema, when defining the data type:
create table y.other_table
(
some_enum x.abc
);
I have an EF 4 data model with TPT mapping.
I have a strange behaviour about the generated SQL of a query .
Lets say entity A is a base entity , A has two derived entities B and C , also A has many associations with other entities (say E,D).
When I make a simple select on A , Context.A.First() , I profiled the generated SQL from this entity and it has all the joins with the other entities.
Do you have a ny suggestion why this happen ? fixes ? any tip.
Thanks in advance ...
Context.A is the set of all A entities - including all B and C entities because every B and C is an A. It is not the set of all A entities that are not a B or C.
Therefore, if you request the first A in the database by Context.A.First() it could be a B or C or just an A. To find the concrete type of that first A the only way with TPT inheritance is to check if there are related records in the B or C table that have the same primary key like the first record in the A table. If there are related records this A is of type B (or C) and all column values from the record in table B (or C) have to be loaded together with the column values from the base record in table A in order to materialize an entity object of the correct type B (or C). If there are no related records in table B or C the concrete type is just an A.
In any case a join to the related B or C tables is required to figure out if there is a record or not and to determine the concrete type of the first A.
So, the joins you are seeing are expected behaviour when you use TPT inheritance and you can't avoid them. It has a negative impact on performance, yes, which is the biggest downside of TPT modeling.
Below link classifies types of table in DB2.
DB2 Table Types
T = Table (untyped)
U = Typed table
V = View (untyped)
W = Typed view
What is the difference between these and which are the conditions where we should use these?
Also, how can we define this during creation of the table ?
Typed table are defined based on UDT (User defined types). They can have levels in a hierarchy and describe the referenced object (from the model), and that description can be re-used in other tables or even in stored procedures. (In order to create a table with the same structure, it is not necessary to do a create like, but a create table based on the type)
Normal tables are defined based on columns, but that definition cannot be re-used in other objets, and it has to be redefined (redefine the column order and precision, etc.)
Take a look at the documentation: http://publib.boulder.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.structypes.doc/doc/c0006606.html
Let'say i have the following tables:
Table A: id b-id
Table B: id property
Can I filter elements of table A like the following in JPQL language?
SELECT a FROM A a JOIN a.b-id targetId WHERE targetId.property = : someValue
I'd like to get table A's elements in which the referenced B element has property = someValue
And if I introduce a third table
Table A: id b-id
Table B: id c-id
Table C: id property
How can I get A's elements where c.property=someValue ?
I'm starting to get a sense of the power of ORM but some concepts are still vague to me.
Thank you for your answer
JPQL queries operate to entities, not to database tables. I assume names of entities and persistent attributes match to the names of tables and database columns given in question.
Because all relations in question are single valued, one-to-one or many-to-one (each A is connected only to one B (or possibly not to any), each B is connected to one C), specifying joins in query is not needed at all.
SELECT a FROM A a WHERE a.b.c.property = someValue
There is no need to worry about null values in path, because as said in JPA 2.0 specification:
Path expression navigability is composed using “inner join” semantics.
That is, if the value of a non-terminal field in the path expression is null,
the path is considered to have no value, and does not participate in the
determination of the result.
Same does not work for collection valued attributes (one-to-many, many-to-many), because it is not possible to navigate to their attributes via path expressions.