Change Table at Load<T> and Serialize<T> without manipulating xml file

Dec 11, 2009 at 11:29 AM


I need to change the destination table at runtime in one Load and Serialize operation. Afterwards I must be the table mapped in the xml file.

How can I do this?


Josep Balague

Apr 22, 2010 at 2:31 PM

Why would you need this ?

I am not sure you can do this easily.

Apr 22, 2010 at 4:26 PM


Some of our tables have this reason (n years * 12 month)

I have found a solution for reading but I'm getting problems in INSERT and UPDATE:

ObjectContext oc;
SqlMapperProvider mp = (SqlMapperProvider)oc.Factory.PersistenceEngineFactory;
EntityMappingCollection emc = mp.Mapping.Entities;
emc[0].Table = "CL201002"; //original value is CLAAAAMM
oc.LoadSingle<CalendarioPresencia>(typeof(CalendarioPresencia), string.Format("[{0}]", constraint));
The output is valid:

SELECT COUNT (*  ) FROM (SELECT 'CalendarioPresencia' AS [EntityType]  , [e0] .[CL_CODI]  AS [pkCL_CODI] , [e0] .[CL_TURN]  AS [SecuenciaTurnos] , [e0] .[CL_ABSE]  AS [SecuenciaAbsentismos] , [e0] .[CL_HOR1]  AS [SecuenciaHoras1] , [e0] .[CL_HOR2]  AS [SecuenciaHoras2] , [e0] .[CL_HOR3]  AS [SecuenciaHoras3] , [e0] .[CL_HOR4]  AS [SecuenciaHoras4] , [e0] .[CL_HOR5]  AS [SecuenciaHoras5] , [e0] .[CL_VACA]  AS [SecuenciaVacaciones] FROM [CL201002]   AS [e0]  WHERE (([e0] .[CL_CODI]  = '00000001' ) ) ) AS [e1] 

Do you see the CL201002 FROM?

But in INSERT and UPDATE .TableName of CacheEntityEntry  is mapped with original xml file definition:

INSERT INTO [CLAAAAMM]  ([CL_CODI] , [CL_TURN] , [CL_ABSE] , [CL_HOR1] , [CL_HOR2] , [CL_HOR3] , [CL_HOR4] , [CL_HOR5] , [CL_VACA]  ) VALUES ( 'a6166542-55dd-432e-a7ad-486c3e0ffc86’ ,  'T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01T01' ,  '' ,  '' ,  '' ,  '' ,  '' ,  '' ,  ''  )

I suggest these posibilities:

1) I would like to change manually commands inside  CacheEntityEntry but this object is not not public.

2) Pass as parameter :

.LoadSingle<T>(type, constraint, physical_table);
.Load<T>(type, constraint, physical_table);
.Serialize(type, physical_table);

and avoid to manipulate internal sctructures as I made for SELECT.


Josep Balague

Apr 22, 2010 at 4:37 PM


Both of your possibilities do not make sense :

1) We indeed do not allow anyone to change the CacheEntityEntry, because it is not supposed to be changed. The behavior you need is really specific. I don't have access to the code right now, so I have to check. Isn't the CacheEntityEntry indexed on the tablename ? so if you change the entitymapping tablename, you would have a new cacheentityentry for this table ?

2) This one does not make sense because if you do not use the SqlMapperPersistenceEngine, the physical_table parameter has no reason to be.


Apr 23, 2010 at 7:31 AM


I understand 2nd option is not a clean solution. Thanks.

CacheEntityEntry is the real problem :

EntityMappingCollection emc = mp.Mapping.Entities;
emc[0].Table = "CL201002"; //original value is CLAAAAMM

CacheEntityEntry should be refreshed from CLAAAAMM to CL201002 automatically for INSERT and UPDATE (why SELECT is working fine?). When you test it, please check commands. Both have original mapping table name but EntityMapping has my changed table name:

InsertCompoundQueryEntries[nnn].Query.TableName = "CLAAAAMM"
UpdateCompoundQueryEntries[nnn].Query.TableName = "CLAAAAMM"

I think I wouldn't need a new cacheentityentry because all CLAAAAMM have identical schema.

Should CacheEntityEntry be synchronized with EntityMappingCollection allways. Shouldn't it?


Apr 23, 2010 at 8:26 AM

Select is working fine, because we can not predict which request you are going to make. Insert and Update are more predictable : Insert, you insert all fields. Update, you update at least one field with a constraint based on the primarykey.

The CacheEntityEntry is based on one assumption : the Mapping won't change at runtime. It's only reason to exist is to have this Insert and Update commands cached not to create them each time whereas their structure is the same. What you may need would be to prevent CacheEntityEntry creation. I will have a look on it asap.