This may be an odd question! But I was wondering if anyone has ever attempted this. I guess the first question most people would ask is why!!
With index server you can add additional meta data to standard file information (name, size etc).
I want to be able to expose this information through to a BL component via nhibernate I need to write - so that when I replace the indexing, I don't have to rewrite the Business logic.
In theory, you would extract interface for indexing provider and then create a wrapper and wrap Micorosoft Index Server. Then when you have different provider, you create a wrapper for the new one and use IoC to inject implementation. I fail to see how NHibernate fits into this.
Related
My entire group is new to ASP.Net Core and I was the lucky one tasked with Authentication/Authorization. We have always used a DB first approach, and this is no different, we already have our DB all set up. The higher ups want to use our specific tables for all things Identity, but they also want to leverage the tools that ASP.Net Core gives.
This will be a multi-site app where there is one central database. Our current setup is close to what the scaffolding adds, but has some small differences.
I have read a ton of resources, but the vast majority all focus on the code first approach and I currently don't fully understand what I need and what is there for the code first approach. I have seen a couple of answers that recommend using the .ToTable and .Property inside of OnModelCreate. Is this the best option or am I better off creating my own stores and methods? I currently have a user model created and a store to go with it (based on this site). Is it best for me to try to expand that all the way out (don't full understand how to have it pull in roles and claims).
This is what our DB Schema currently looks like.
At this point we are creating our Roles and Claims via a db script. The only thing we will be using UI's for right now is a page that will let a site admin add users, and assign them roles, and any singular claims they need.
Any help or input would be greatly appreciated as I try to wrap my head around all of this. If I have left out any pertinent information please let me know. As I said with what I have now I can create a user and login, I just have no idea where to go from here (how to add roles and claims).
Here's how I think about it and the steps I would take to approach in solving this problem.
So Microsoft's implementation of Identity is an abstraction of the problem.
The Models that they provide and the Tables that are derived from them is their choice for the default implementation of the abstraction.
So essentially what you want to do is to plug in your models in to this abstraction.
To quickly generate these models from your database you might want to use scaffolding this will generate the DbContext and the Models, you will then have to configure the dbcontext to plug in your design.
And if you look at how you can create your own Identity Tables providing your own objects
here this can give you an idea of how to plug in your models/functions in to this abstraction.
You will most likely have to override the OnModelCreating method to configure the relationship of your tables.
I am wondering what jhipster entities are exactly?
What if I just want to create a new page/view without any database entry and relationship? For example: the about page, do I have to use the entity generator in order to create it? What are the benefits of it?
jhipster entity tutorial
Regards
redyar
Entities are typically objects that are backed by a database table. With JHipster, you can generate entities (and their associated screens) using Yeoman.
For an about page, or any other page, you can author them by hand. You don't need to use a generator. JHipster merely provides its entity sub-generator as a convenience for you.
You can also use the Yeoman generator for AngularJS to generate basic scaffolding.
http://yeoman.io
Immagine to build a website of e-commerce. That website contains users, sensible data informations, details about sellers and other things. You can save a lot of time creating it with Jhipster because it automatically create Objects class that represents database's tables, RESTful web services to manage them and the frontend view with Angular, CSS and HTML (all generated automatically). The objects that represent database's tables are entities.
With entities you can do CRUD queries on database using Java objects and Java methods with Spring framework. You can do queries by calling java methods. Thats all! After some practice it's really easy to use.
With that generator you don't have to configure relationships, constraints or things like that. Jhipster does that for you!
If you need a web application that does not use a database you don't need to use a generator like this, in my opinion.
I took the right Matt Raible's answer trying to give you more informations about entities. I hope to be helpful!
Have a nice day!
how can i handle read authentication in couchdb? i know roles can be defined in seperate databases but i want to implement read authentication on document level. i am thinking about using node.js but it does not seem an elegant solution because couchdb also has a http server and i dont want to add one more (or another application server like ruby or python). is there anyone working on this?
Thanks.
In the recent O'Reilly web cast on CouchDB, J. Chris Anderson mentioned that read authentication was best handled by a combination of partial replication and multiple databases per reader group. Each database would contain only the documents pertaining to that specific group.
It makes the most sense when you think of each readers CouchDB as a filtered instance of an authority database.
That's basically the correct answer. What I'd add is that document-level read control is hard to get right, especially in the presence of views. Filtering map rows at read-time is doable, but not very IO efficient. Generate reduction values based on filtered map rows, however, is prohibitively expensive.
For those reasons we encourage you to operate something like a database per access group, and make the entire database readable by all users.
I have large and complex SQL Server 2005 DB used by multiple applications. I want to create a data-dictionary for maintaining not only my DB objects but also cross-reference them against applications that use a specific object.
For example, if a stored procedure is used by 15 diffrent applications I want to record that additional data too.
What are the key elements to be kept in mind so that I get a efficient and scalable Data Dictionary?
So, I recently helped to build a data dictionary for a very large product. We were dealing with documenting more than one-thousand tables using a change request process. I can send you a scrubbed version of the spreadsheet we used if you want. Basically, we captured the following:
Column Name
Data Type
Length
Scale (for decimals)
Whether the column is custom for the application(s) or a default column
Which application(s)/component(s) the column is used in
Release the column was introduced in
Business definition
We also captured information about who requested the addition, their contact information, etc. Our primary focus was on business definition, and clearly identifying why a column was being used or created.
We didn't have stored procedures in our solution, but bear in mind that these would be pretty easy to add to the system.
We used Access for our front-end, even though SQL Server was on the back end. It made it pretty easy for us to build out a rich user interface without much work, using the schema we had already built out.
Hope this helps you get started--feel free to ask if you have additional questions.
I've always been a fan of using the 'extended properties' within SQL Server for storing this kind of meta data. In this way the description of each object lives alongside the object and is accessible by anyone with access to the database itself. I'm sure there are also tools out there that can read these extended properties and turn them into a nicely formatted document.
As far as being "scalable", I don't know of any issues related to adding large amounts of data as extended properties; or I should say I've never had any issues with this.
You can set these extended properties using SQL Server Management Studio 'property' dialog for each table/proc/function/etc and can also use the 'sp_addextendedproperty'.
For instance, will I be able to create an application that allows users to create and modify existing types at runtime? Will I be able to persist instances of those types in SQL without having to worry about the user who adds 100,000 records and expects a (really) fast query on them?
Think SharePoint Content Types... but on steroids. Oslo steroids - Possible or not?
That would be awesome!
In the demos, they create the new extent, and then a (updatable) view with the old name.
But I haven't heard about a feature that would automatically merge existing data into the new structure, though. For now, they suggest using SQL Server Integration Services for that part - but then it's a DB-Admin task.
Regarding performance, after MSchema is compiled to SQL statements, it's all plain SQL Server performance.