We have a lots of Entity and we are trying to limit the number of SQL objects generated by CodeFluent Entity. We are using some lightViews but I have the feeling that a lot of generated views are useless. Is it possible to decide Entity by entity to produce view or not ? (I'm aware of the produceViews option on the SQL producer but we still need some views)
Can we choose not to generate views by Entity?
38 Views Asked by vinz_leconte At
1
There are 1 best solutions below
Related Questions in CODEFLUENT
- Error 'Could not open a connection to SQL Server' while upgrading database with codefluent pivot runner
- How to create an Aspect in Codefluent
- Converting function from Code Fluent to Entity Framework
- Migrate from Code Fluent to Entity Framework
- Migrate from Code Fluent to Entity Framework (.net)
- Codefluent Entities and .net Identity
- Producer does not put messages in default resource file (BusinessLayer.ResX)
- Is it possible to create a "Private" CFQL Method?
- Can a Raw SQL method that doesn't return data be called from the collection object?
- Solution to Error: ORDER BY items must appear in the select list if SELECT DISTINCT is specified
- Codefluent execution timeout
- Foreign Keys generated as NOCHECK
- How load / save blobs from / to Azure blob storage?
- MyPivoRunner & Progress bar control
- Can we choose not to generate views by Entity?
Trending Questions
- UIImageView Frame Doesn't Reflect Constraints
- Is it possible to use adb commands to click on a view by finding its ID?
- How to create a new web character symbol recognizable by html/javascript?
- Why isn't my CSS3 animation smooth in Google Chrome (but very smooth on other browsers)?
- Heap Gives Page Fault
- Connect ffmpeg to Visual Studio 2008
- Both Object- and ValueAnimator jumps when Duration is set above API LvL 24
- How to avoid default initialization of objects in std::vector?
- second argument of the command line arguments in a format other than char** argv or char* argv[]
- How to improve efficiency of algorithm which generates next lexicographic permutation?
- Navigating to the another actvity app getting crash in android
- How to read the particular message format in android and store in sqlite database?
- Resetting inventory status after order is cancelled
- Efficiently compute powers of X in SSE/AVX
- Insert into an external database using ajax and php : POST 500 (Internal Server Error)
Popular # Hahtags
Popular Questions
- How do I undo the most recent local commits in Git?
- How can I remove a specific item from an array in JavaScript?
- How do I delete a Git branch locally and remotely?
- Find all files containing a specific text (string) on Linux?
- How do I revert a Git repository to a previous commit?
- How do I create an HTML button that acts like a link?
- How do I check out a remote Git branch?
- How do I force "git pull" to overwrite local files?
- How do I list all files of a directory?
- How to check whether a string contains a substring in JavaScript?
- How do I redirect to another webpage?
- How can I iterate over rows in a Pandas DataFrame?
- How do I convert a String to an int in Java?
- Does Python have a string 'contains' substring method?
- How do I check if a string contains a specific word?
No this is not an option. The produceViews attribute only related to persistent views explicitly defined in your model.
Now : if you are completely in control of what you can use, sure you are not referencing some default generated views in any model attribute, any methods (CFSQL or raw SQL), or partial code, then here some ideas :
You can choose not to use the default generated xx_views.sql : - do not keep it in sourcecontrol - provide your own views (the persistent known ones extraceted from the generated file) in a custom post SQL script after_[DefaultNamespace]_views.sql : in it you could for instance delete all existing views, then declare only the ones you want to use. It would be a manual step that can be time consuming if your persistent views are changing a lot between versions. May be a good name convention for persistent views will help this manual report for a good enough solution.
Another more advanced and cleaner idea would be to provide a custom aspect removing the "default" view created for each entity in the meta model before production (see infered meta model and CodeFluent.Model.Entity class), except for entities marked with a custom attribute. This is an idea not guaranted/tested.