I'm working on a project that I need to define a model from SQL Server views. Is it possible to define a model from views according to not to use table joins and decrease complexities.
Yes, you can point a Sequelize model at a view, rather than a table at least for SELECT statements (e.g. model.findAll()) I doubt that model.sync() would work against a view, but haven't tested. IIRC, some databases allow INSERT, UPDATE or DELETE against views in limited cases) and in those limited cases you might be able to use model.create(), model.update() or model.delete() also.
sequelize.sync() creates the models assuming that you only want to work with tables and tries to create a table when you actually want a view... as per the example below
Error message when the view already exists
In OBJECT_ID('V_Funds','U') 'U' is for Table.(cf. image)
So forget about using sequelize.sync() and just use Sequelize-Auto (as per the comments above). Then just run a simple .bat or .cmd such as the one below and all is done for you automatically
rem recreate the various models
node node_modules\sequelize-auto\bin\sequelize-auto -h localhost -d XXXX -e mssql -u sa -x PASSWORD -c "./config.json" -o "./../server/src/models"
Related
I'm trying to do sequelize migrations on the models I created such as User.js, Blogs.js etc... What I've noticed is that I can add columns to Models like User.js and Blogs.js, but if I dont change the files in my models folder, the changes will be recognized in the database, but I wont be able to access the new columns when the server is running.
EG:
I add column permission: {type: Sequelize.STRING} to User.js.
I can't access this column because my original model file doesn't contain permission. Do I have to delete the models, and then create them using the sequelize-cli in order to get the migrations to also update the model files?
Your question is somewhat unclear.
In order to add a new column to a table using Sequelize migrations, you need to do the following steps:
Generate a new migration file.
Using queryInterface methods, make the changes to your tables in the migration file.
Execute your migrations.
Update your models with any new properties that are added.
Restart your server.
Keep in mind that migrations are done as an ALTERNATIVE to using the sequelize.sync() method. If you are using the sync() method, you cannot add columns to a table without using the { force: true } flag inside of sync(), which causes your tables to be dropped and data lost. Migrations are a process that requires a bit more attention to be paid, but they are a feasible long-term solution for a production database.
The entry for that screen is not needed. All the records are automatically generated. or probably by using DAC only.
The Graph/DAC logic is preferred as you get all of the framework freebies such as field defaulting and calculated formula fields.
You can however get around this using PXDatabase.Insert or PXDatabase.Update PXDatabase.Delete
I use these for upgrade processes or bulk delete of processing records. These calls do not require a graph to execute but ignore all DAC attributes which may or may not default values, calculate values, etc.
If you search on PXDatabase in the Acumatica code browser you can find examples. Here is one from EmployeeMaint.Location_RowPersisted:
PXDatabase.Update<Location>(
new PXDataFieldAssign("VAPAccountLocationID", _KeyToAbort),
new PXDataFieldRestrict("LocationID", _KeyToAbort),
PXDataFieldRestrict.OperationSwitchAllowed);
PXDataFieldAssign is setting column values.
PXDataFieldRestrict is your where condition.
It is best to find multiple examples of PXDatabase in Acumatica and confirm your query results using a tool such as SQL profiler to make sure its executing the correct statement you intend to run.
You can't use DAC without Graph. All BQL queries require PXGraph instance. The only way to save data without using BQL is using ODBC or any other ORM to connect strictly to database and do your changes. But it is not recommended way as in case of doing it in that way you will ignore all the Business Logic.
Currently I'm working on an application that is making queries on a given MarkLogic database, the default one as we can say, but to provide same values on the screen I have to check the role of the logged user before displaying. This can be done querying the Security database, the one provided by MarkLogic itself, but I don't know how to explicitly declare on the query that I want to query that particular database instead of the default one. Do you know some command that could help me? Thank you!
You can use eval to query against another database:
xdmp:eval("doc('/docs/mydoc.xml')", (),
<options xmlns="xdmp:eval">
<database>{xdmp:database("otherdb")}</database>
</options>)
See: https://docs.marklogic.com/xdmp:eval
Also, if you are querying the security database specifically, then instead of xdmp:database you can use xdmp:security-database.
I re-created my database on one of my dev environment and now when I run the migration via sequelize db:migrate, it tries to run the migrations from the first.
I don't want to re-sync/re-create the database since running migrations on the dev environment ensures that the migrations are correctly written.
Is there a way to force-mark some migrations as 'done'?
Sequelize-cli stores the migration data on a table called SequelizeMeta.
You can copy the migration filename from your existing DB and insert into the above mentioned table in new environment's DB.
All the migrations recorded would be considered as they have already ran.
Though this would stop selected migrations from running, it's not the best approach to be taken.
This metadata could also be stored in a json, though I am not very aware of the structure for it.
You can dig through the docs here
The actual way of doing is as follow,
There are two tables sequelizemeta and SequelizeMeta(Hidden)
And for skip or say migration already ran is enter value in both table like
INSERT INTO sequelizemeta (name) VALUES
('20181019072815-roles.js'),
('20181019093229-users.js')
INSERT INTO SequelizeMeta (name) VALUES
('20181019072815-roles.js'),
('20181019093229-users.js')
Note- SequelizeMeta is hidden table but we can query it.
SELECT * from seerportal.SequelizeMeta
I am looking at the documentation for Meteor and it gives a few examples. I'm a bit confused about two things: First, where do you build the db (keeping security in mind)? Do I keep it all in the server/private folder to restrict client-side access? And second, how do I define the structure? For example, the code they show:
Rooms = new Meteor.Collection("rooms");
Messages = new Meteor.Collection("messages");
Parties = new Meteor.Collection("parties");
Rooms.insert({name: "Conference Room A"});
var myRooms = Rooms.find({}).fetch();
Messages.insert({text: "Hello world", room: myRooms[0]._id});
Parties.insert({name: "Super Bowl Party"});
I don't understand how a collection's structure is defined. Are they just able to define a collection and throw arbitrary data into it?
To answer your first question about where to put the new Meteor.Collection statements, they should go in a .js file in a folder accessible by both client and server, such as /collections. (With some exceptions: any collections that are never synced to the client, like server logs, should be defined inside /server somewhere; and any local collections should be defined in client code.)
As for your second question about structure: MongoDB is a document database, which by definition has no structure. Per the docs:
A database holds a set of collections. A collection holds a set of
documents. A document is a set of key-value pairs. Documents have
dynamic schema. Dynamic schema means that documents in the same
collection do not need to have the same set of fields or structure,
and common fields in a collection’s documents may hold different types
of data.
You may also have heard this called NoSQL. Each document (record in SQL parlance) can have different fields. Hence, there's no place where you define initial structure for a collection; each document gets its "structure" defined when it's inserted or updated.
In practice, I like to create a block comment above each new Meteor.Collection statement explaining what I intend the structure to be for most or all documents in that collection, so I have something to refer to later on when I insert or update the collection's documents. But it's up to me in those insert or update functions to follow whatever structure I define for myself.
A good practice would probably be defining your collection on both client and server with a single bit of javascript code. In other words, put the following
MyCollection = new Meteor.Collection("rooms");
// ...
anywhere but neither in the client nor in the server directory. Note that this directive alone does not expose any sensitive data to nobody.
A brand new meteor project would contain by default the insecure and autopublish packages. The former will basically allow any client to alter your database in every possible way, i.e. insert, update and remove documents. The latter will make sure that all database content is published to everyone, no matter how ridiculously this may sound. But fear not! Their only goal is to simplify the development process at the very early stage. You should get rid of these to guys from your project as soon as you start considering security issues of any kind.
As soon as the insecure package is removed from your project you can control the database privileges by defining MyCollection.allow and MyCollection.deny rules. Please check the documentation for more details. The only thing I would like to mention here is that this code should probably be considered as a sensitive one, so I guess you should put it into your server directory.
Removing the autopublish package has effect on the set of data that will be sent to your clients. Again you can control it and define privilages of your choice by implementing a custom Meteor.publish routine. This is all documented here. Here, you have no option. The code can only run in the server environment, so the best choice would be to put it in the server directory.
About your second question. The whole buzz about NoSQL databases (like mongodb) is to put as few restrictions on the structure of your database as possible. In other words, how the collections are structured is only up to you. You don't have to define no models and you can change the structure of your documents (and or remove fields) any time you want. Doesn't it sound great? :)