How can I remove the prefix of the foreign key column names?

Jul 16, 2015 at 3:10 PM
Edited Jul 16, 2015 at 3:13 PM
When I looked at the tables generated by Vita, I saw that all the columns that are foreign keys are prefixed with the name of their original table. I have named the primary keys in such a way they are unique in the entire DB. Is there any way I can turn off this prefixing? and if so, will it rename the columns (perhaps I need the OldNames attribute)?

Kind Regards,
Reza.
Coordinator
Jul 16, 2015 at 5:13 PM
The FK column name is concatenation of property name and target FK. You can specify the column name explicitly using EntityRef attribute and provide it with column name(s)
Marked as answer by irezax on 7/17/2015 at 12:33 AM
Jul 17, 2015 at 7:46 AM
Thank you, I'm starting to like your framework ;) (then it will be the one and only ORM I like! ) I'm still skeptic about the logging and security implementation. BTW most of stuff so far look very similar to way I do things.

I am also curious about few things, here under a few:
  • What is the purpose of [ForEntity] attribute?
  • How can I call Stored Procedures?
  • Can I customize the SP generation?
  • Can I call a Scaler function?
Coordinator
Jul 17, 2015 at 4:21 PM
thanks... may I ask, what particular things in logging and security keep you skeptic?
ForEntity attribute - for companion types, that are used to separately specify keys and indexes on entities; when companion type is not derived from the entity that it is companion to, ForEntity will specify the relation explicitly. See BooksEntityKeys.cs file for example of companion types
Call stored procedures - for now, only through directDbAccess facility, when you obtain IDbConnection to db and use it for whatever you want.
Customize SP generation - sub-class DbDriver and DbSqlBuilder, override particular methods, just like all drivers do
Scaler function? you mean Scalar? same as with stored procs.
Marked as answer by irezax on 7/22/2015 at 6:08 AM
Jul 22, 2015 at 1:08 PM
Thanks again! and yes Scalar :D
To be honest I have not yet dig into any of those, but I didn't liked the fact that when I just wanted to have a minimal ORM the App and all the things around it was imposed even though if there is nothing wrong in it and it's free :) I'm more in favor of minimal packages with minimum impact that you pick those you need. I know that's a bit of perfectionism and I could leave them there, but imagine if the components were so decoupled that one could pick only say the data access part if need be and gradually add the other if he/she likes to. What do you think? maybe I overlooked something?
Coordinator
Jul 22, 2015 at 6:00 PM
Hmm.. why do you see all this extra stuff as imposed and forced on you? all this logging, caching, authorization are hidden inside, and are mostly internal hooks that might be left inactive. Look at Quick Start guide - everything is bare minimum. It is only if you move to a real world app, you will really need all these things - and wonderful thing is that they can be be enabled at startup, and do the job in the background. Your code is not littered with all these "Log(...)", "if(Cache.GetStuff()", "if(user.IsAllowedToRead(someobject))", etc. This is the important thing ORM developers (EF folks included) do not get - an ORM must have all these built-in, otherwise it is useless in real world apps. Because enabling logging, caching, locking, authorization on top of a 'simple' ORM causes so much mess, that gains from using ORM completely disappear.
That's my take on things.
Jul 24, 2015 at 10:51 AM
Edited Jul 24, 2015 at 10:52 AM
I understand your point and am agree with the fact that having built-in logging, caching, and other important application blocks inside the ORM bring a lot of value, but I'm also curious to know how replacable they are and maybe it's the name of EntityApp class that was a bit misleading for me, as I had already an xxxxApp class in my project. Let's take an example to make sure we fully understand each other:

Imagine I have a LoB application with all the common application blocks in place. I have Logging, Configuration,... the only missing part is the Data Access (though I also believe that Authorization should be built-into the data access for most of the cases). And now the questions:
  • How can I make sure that I have a unified Logging,... in my application?
  • To make the matter a bit more complex :) what if I bring AOP to the picture for lets say Logging or Authorization (attributes on top of methods,...).?
Coordinator
Jul 24, 2015 at 5:21 PM
Well, first of all, very unrealistic situation - you have a LOB app, and you wanna replace data access (does it ever happen?!), and on top of this, you wanna keep other things like Logging. Compared to data access, Logging is a secondary, diagnostic service, is not part stricter compatibility restrictions; end user never sees it, who cares even if you change it? It is not a core business functionality, so switching it is not like changing a financial transaction engine or tax calculation module.
Given all that unrealistic nature of the scenario, still I think VITA provides logging solution that is flexible enough to flip in and out. All logs are hooked as services inside EntityApp which is a service container. Initialize the app and register IErrorLogService of your own making - and you have your custom logging inside VITA entity app. All you need is a tiny adapter from IErrorLogService call to your custom MyLogger implementation.
The reverse is also easy - create an instance of LoggingEntityApp (in Vita.Modules), connect it, then call app.GetService<IErrorLogService>() and you can use this log service anywhere else, inside old LOB app, or inside biz app built on top of VITA. Or in AOP-like scenario, inside attribute implementations.

About Vita log modules - don't dismiss them as just another kind of a simple thing. All loggers I've seen are not efficient and robust. I've spent a lot of time on this, and VITA's logging is the result of a long efficiency optimization. Like one thing - log entries are not written immediately, but thrown to a background async queue, so that there's minimum delay for the main thread. The queue is flushed on background thread, using SQL batching, with tens or even hundreds entries in one roundtrip. Even formatting is done on background thread (like writing out text representation of Db command and its parameters). So, don't dismiss it too early.
AOP - not a big fan, at least the way they tried to build in the past. While the concept seems nice (as they all are), the actual implementations that appeared are far from satisfactory.
Jul 25, 2015 at 5:17 PM
I forgot to mention that I'm just talking about the design of an application here, normally the common application blocks are already preselected by other teams in my company to unify and sometimes centralize things and make sure developpers are following best practices. But the things you explained about Vita's logging makes it interesting, I'm going to extend my PoS to look into other areas of Vita more deeply. Thanks for your time. I hope I don't bore you to death with my questions ;)



On Fri, Jul 24, 2015 at 10:22 AM -0700, "rivantsov" <[email removed]> wrote:

From: rivantsov

Well, first of all, very unrealistic situation - you have a LOB app, and you wanna replace data access (does it ever happen?!), and on top of this, you wanna keep other things like Logging. Compared to data access, Logging is a secondary, diagnostic service, is not part stricter compatibility restrictions; end user never sees it, who cares even if you change it? It is not a core business functionality, so switching it is not like changing a financial transaction engine or tax calculation module.
Given all that unrealistic nature of the scenario, still I think VITA provides logging solution that is flexible enough to flip in and out. All logs are hooked as services inside EntityApp which is a service container. Initialize the app and register IErrorLogService of your own making - and you have your custom logging inside VITA entity app. All you need is a tiny adapter from IErrorLogService call to your custom MyLogger implementation.
The reverse is also easy - create an instance of LoggingEntityApp (in Vita.Modules), connect it, then call app.GetService<IErrorLogService>() and you can use this log service anywhere else, inside old LOB app, or inside biz app built on top of VITA. Or in AOP-like scenario, inside attribute implementations.

About Vita log modules - don't dismiss them as just another kind of a simple thing. All loggers I've seen are not efficient and robust. I've spent a lot of time on this, and VITA's logging is the result of a long efficiency optimization. Like one thing - log entries are not written immediately, but thrown to a background async queue, so that there's minimum delay for the main thread. The queue is flushed on background thread, using SQL batching, with tens or even hundreds entries in one roundtrip. Even formatting is done on background thread (like writing out text representation of Db command and its parameters). So, don't dismiss it too early.
AOP - not a big fan, at least the way they tried to build in the past. While the concept seems nice (as they all are), the actual implementations that appeared are far from satisfactory.