I am interfacing dynatree to a relational database. I drag and drop nodes from a source tree into a target tree. When the drop is complete I need to access the unique key value automatically assigned to the dropped node in the target tree. I am using:
copynode = sourceNode.toDict(true, function(dict){
...
delete dict.key; // Remove key, so a new one will be created
});
I need the unique node key value because you can't depend on node names for uniqueness. Once I've got the key I can figure out where in the tree the node was dropped and update the database. How do you get the new node key?
Assuming you use node.addChild(copynode): this function returns the first newly created node, which should contain the new key.
Another option would be to generate and set your own unique key, instead of removing it and depending on Dynatree to create one.
Related
I got a question regarding id's inside an event sourcing architecture.
Since it's the goal to have a rebuildable state using the eventstore, the data projection should have a deterministic generation of primary keys for the current state data.
e.g.: when i create and then delete an entry afterwards, i save the id of the deleted item into the event store entry. Now when I want to rebuild my state from the Eventstore, the created item event should generate the same id into the projection - to be able to run the deleted event properly.
Does this mean i cannot use random UUID's or am i missing something?
When you start a rebuild of your read-model, then you could reset the "counter" that the automatic primary key generation value is based up-on. So that each time you do a rebuild, the primary-key always starts with for example 1.
How that is done depends on the database used.
Alternatively, you could just set the primary key manually using a counter in your code "somehow".
I have two tables in MSSQL which are related tbl1.PK tbl2.PK, tbl2FK(_tbl1PK)
I have created a dataset in Visual Studio and they show up with the relation
when I drop the tables as datagrids onto a form I get the parentDG and childDG.
VS adds in the binding navigator which adds the save procedure
tbl1.bindingsource.endedit
tableadaptermanager.updateall
When I add data to the parentDG and press save the data gets saved to the DB.
When I add a new parent and then add a new child details and press save I get
System.Data.SqlClient.SqlException: 'The INSERT statement conflicted with the FOREIGN KEY constraint "FK_tblChild_tblParent". The conflict occurred in database "xxxxx", table "dbo.tblParent", column 'PK'.
I have tried updating the parentTableadapter and then ds.acceptchanges but I can not get the new child row to update.
I understand why but my questions are:
isn't the VS IDE supposed to handle this?
if isn't for me so I presume I need to get the new tbl1PK (scope_identity).
I can see in the dataset code the insert command:
Me._adapter.InsertCommand.CommandText = "INSERT INTO [] FROM tbl1 WHERE (PK= SCOPE_IDENTITY())"
BUT I cannot for the life of me see how to get this value.
I have a lot of tables with a lot of columns which is why I want/need to use the power of the IDE to populate and bind my controls and so I really do not want to go down the route of manually creating my datasets.
I have searched and searched on this and can't find anything that speaks to how you do this using VS auto generated code.
thanks
John
I just tested and the addition of the query in the InsertCommand happened automatically so you must not have done something properly. Here's EXACTLY what I did:
Created a new database named Test on my local default SQL Server instance via SSMS.
Added a table named Parent with columns ParentId (int, PK, identity) and ParentName (varchar).
Added a table named Child with columns ChildId (int, PK, identity), ParentId (int) and ChildName (varchar).
Created a foreign key in the Child table to the ParentId column from the ParentId column in the Parent table, setting the Update Rule to Cascade.
Created a new VB Windows Forms application project.
Added a new Data Source via the Data Sources window for the Test database.
Opened the TestDataSet from the Solution Explorer in the DataSet designer.
Selected the DataRelation between the two DataTables.
In the Properties window, clicked Edit Relation.
Checked 'Both Relation and Foreign Key Constraint', when Update Rule changed automatically to Cascade.
At this point, but even after step 7, I was able to select the ParentTableAdapter in the designer, expand the InsertCommand and view the CommandText to see this:
INSERT INTO [dbo].[Parent] ([ParentName]) VALUES (#ParentName);
SELECT ParentId, ParentName FROM Parent WHERE (ParentId = SCOPE_IDENTITY())
If you don't see that, you can set it yourself. What happens now is that, when the InsertCommand is executed to insert a new record, that query immediately retrieves the data from that record back into the DataRow in your DataSet. That will update the ParentId column with the newly generated value and the Update Rule will cause that new value to cascade to any related DataRows in the Child DataTable, so you can just go ahead and insert them without worry.
I have the database:
Node(nno,color)
edge(eno,head,tail,weight,gno)
graph(gno,gname)
bold here represents primary key
and the graphh is directed: head -> tail
how can I build a trigger to check whether or not , with each insert of a node to the graph , the graph is connected? meaning there is a path between every two nodes
How do I even check if there is path between each two nodes ?
I am using postgreSQL
This is an X-Y problem, and most likely unworkable using a trigger: If referential integrity is to be maintained with foreign keys (definitely desirable) then by definition the insertion of a node will create a disconnected graph, and be rejected.
The solution is to have a stored procedure through which all inserts to all three tables are passed, and which only accepts connected graph additions.
Given the assumption that a given graph is already connected, then for an extension to a given graph to be accepted it is sufficient for every node in the extension to be connected to any one node in the existing graph.
I want to know, if the two settings node_auto_indexing and relationship_auto_indexing in the neo4j.properties concerning the ids of nodes and rels?
or creates neo4j automatically an index for the ids of the inserted nodes and rels?
the auto index creates index for all properties defined at the *_keys_indexable line in the neo4j.properties file.
the index then bounds the node ID with the specific property value. thus, searching the index for the the property value will return the node.
since your question is a bit unclear to me, you might want to take a look at official docu:
http://docs.neo4j.org/chunked/milestone/auto-indexing.html
No you shouldn't add your ID to the auto index. There is no use for it, since you can already retrieve nodes by ID, without using auto index.
There are however occassions where the usual ID is not sufficient. For instance, when working with users, you may have a user id of some kind. You'd then store this in a property, and add that property to the auto index. This way, you can search by user id. Underlying, Neo4J matches your custom user ID, with the actual node id.
Important to keep in mind here is that per definition, auto index is not unique. You need to design your application in such a fashion that the property is in fact unique, if you're expecting a single node result.
Suppose you have two tables that are in a one-to-one relationship; i.e. the primary key of the child table is also the foreign key that links it to the parent table. Suppose also that the primary key of the parent is an identity field (a monotonically increasing integer that is assigned by the database when the record is inserted).
Suppose that you need to copy records from these two tables into a second pair of identical tables -- the primary key of the parent is an identity, and the foreign key linking the child to the parent is also the child's primary key.
How should I copy records from one set of tables to the other set?
I currently have three solutions, but I'd like to know if there are others that are better.
Option 1: Temporarily disable the
identity property in the destination
parent table. Copy records from the
parent table, then the child table,
keeping the same values for the
primary key. Cross your fingers that
there are no conflicts (value of
primary key of source table already
exists in destination table).
Option 2: Temporarily add a column to
the destination parent table to hold
the "old" (source) primary key. Copy
records from the parent table,
allowing the database to assign a new
primary key but saving the old
primary key in the temporary column.
Copy records from the child table,
joining the source child table to the
destination parent table via the the
old primary key, using the join to
insert the record into the
destination child table with the new
primary key. Drop the temporary
column from the destination parent
table.
Option 3: Copy sequentially
record-by-record, first from parent
to parent, then child to child, using
DB-provided "identity of last
inserted record" functions to ensure
that the link is maintained.
Of these options, I think option 2 is my preference. Does anyone prefer one of the other two options, and if so, why? Does anyone have a different solution that is "better"?
This is one reason why it is so critical to remember that even if you use a surrogate key (like an identity column), you always need a business key. I.e., there always need to be some other unique constraint on the table. If you had that, then another choice would be to insert the values into the copy of the parent table without the identity values and use that unique key to insert the proper parent value for the child rows.
If you do not have that unique key, then given your situation, I agree that your best solution would likely be Option #2.
Before you decide on an approach to copy data to new set of tables, you should investigate following items:
a list of tables that reference the data from the parent and child tables (both sets of tables)
Are there any stored procedures/triggers that utilize the data in these tables?
How does this table get populated? Is there an application/data feed that inserts data in this table?
How does the data in this table get deleted?
What is the purpose of the primary key beyond ensuring uniqueness in the table? For this you will have to understand how the data in the table is used by the application.
Based on the answers, you should be able to pick the right solution that will meet the requirements of the application.
My money is on Option 1 (see SET IDENTITY INSERT, http://msdn.microsoft.com/en-us/library/ms188059.aspx).
But: Why are you copying them?
If you are just altering the table schema, or migrating to new tables and retiring the old ones, why not use ALTER TABLE.
If you are going to run them side-by-side you probably need the keys to match.
But to answer your question, use Option 1, definitely.