match, iterate, create and create relationship assistance - cypher

Using this pseudo code, how can I do this entirely in cypher?
match-all nodes with the property of type: Images
using properties from the original match
match using the properties from the main match for type: Parent nodes
if no nodes of the parameters with the type: Parent
create a new node using the parameters and type: Parent
match using the properties from the main match for type: Parent nodes
create a parent -> image relationship, using the node from the initial match and the match for type: Parent node

Related

SQL query - fetch last nodes from graph/tree

I'm looking for help. I want to fetch the last node in the tree. Having a table and data in that table creates a tree structure like here:
Node 0
/ \
Node 1 Node 2
/ \ \
Node 3 Node 4 <-- Node 5 <--
/
Node 6 <--
Each node has an id and parentId. So Node1 has id: 1 and parentId: 0 that connects it with the upper node.
Node columns:
Id
parentId (upper node)
What I want:
So when I choose node 0, I want to "go down" and get back nodes 6, 4, and 5. And when I choose node 1 I want to fetch nodes 6 and 4. The last nodes of the structure. I don't want intermediate nodes.
I tried doing a common table expression, with .. as. But I get intermediate nodes and that's a mess in my case.
Jpa solution is also appreciated.
Thanks and good luck ;)
Considering the following JPA model :
#Entity
class Node {
#Id
long id;
#ManyToOne
Node parent;
}
The leaves of the tree are the nodes not being a parent node.
If all the nodes of your model belongs to the same unique tree, the following request can be done :
SELECT n FROM Node n WHERE n NOT IN (SELECT p FROM Node p WHERE p.parent = n)
If you store several trees in your db or if you want the leaves under a specific node there is no way to build a recursive JPA query.
However, if there is not too much data in your Db, you can load all leaves (whatever node they belong to) with the same JPA request, and recursively scan each node in memory keeping those whose ancestor is the specific node limiting your scope.
BTW, if your store severeal trees in your Db, modifying the initial JPA model helps loading all the nodes of a tree with one JPA request.
Then do all kind of search in memory.
The model must be extended by adding on each node a relation to the root node :
#Entity
class Node {
#Id
long id;
#ManyToOne
Node parent;
#ManyToOne
Node root;
}
With such a model, the complete set of nodes of a tree can be loaded with one request :
SELECT n FROM node WHERE p.root.id = :id_of_the_wanted_root

Multiple `find_with_related()` in sea_orm

Let's say I have a parent::Entity with zero or many good_child::Entity, neutral_child::Entity, and chaotic_child::Entity. (Just an example. The actual child_* tables have nothing in common with one another).
Each child has a field with its parent's id. Now I can select all good_children for some parent with
let (parent, good_children) = model::parent::Entity::find_by_id(42)
.find_with_related(model::good_child::Entity)
.all(&db.begin().await.map_err(…)?)
.await
.map_err(…)?
.pop()
.ok_or(…)?;
But how can I get the neutral and chaotic children in the same query? Simply adding another find_with_related() call does not work:
no method named find_with_related found for struct SelectTwoMany in the current scope
method not found in SelectTwoMany<…::parent::Entity, projektdb_model::good_child::Entity>

Any way in Grails 3 for hasOne to do a lazy fetch?

Grails 3.2.5. Is see from my sql dump that the hasOne relationship does an eager fetch. This used to be the case back in prior versions of Grails, and the behavior could not be overridden. Is this still the case? What is the recommended model for a 1:1 relationship where we want a lazy fetch on the dependent object?
A little background. My "Comment" object has a one-to-one relationship with a "CommentText" object, where the text object holds Oracle clob text - some of it large. I only wanted to get the text when explicitly required to do so. The fk was in the dependent database text object, hence the "hasOne". Fortunately I was able to move the fk to the owner side of the association via an embedded domain object and update the db schema.
Throughout, I was unable to get lazy loading of the hasOne dependent object. Tried fetch: 'lazy'; fetchMode: 'lazy, and other variations of things. I needed a full domain class association because of "find" actions that needed to traverse the association.
I would still prefer the hasOne approach, if loading were indeed lazy.
Old question, but I just encountered the same problem so I'll answer for later reference.
Basically, it is impossible to lazy-fetch a hasOne property in Grails 3 (tested with 3.3.11, assuming Hibernate). But there are some workarounds.
The immediate lazy-fetch N+1 problem
As soon as you put hasOne: [child: Child] on the parent class, GORM will force you to make the relationship into a bidirectional one-to-one, and it will put the foreign key on the child table.
When you then fetch entities of the parent, it will immediately fetch all of the child entities as well, but it will do a query for every child (N+1 problem).
So a statement like this
Parent.list(max: 10)
will issue one query to get the 10 parents, and then do a query where parent_id = ? for each of the 10 children.
Even if you put fetch: 'lazy' and batchSize: 10 on the mapping of the child in Parent.groovy, the behavior is the same.
Workaround 1: One-directional with FK on the parent table
This is the solution you mention in your post. If you don't need to access the parent from the child side, you can make the relationship one-directional, which will put the FK on the parent table.
Now when fetching the Parent entity it will fetch the child_id from the parent table automatically, but keep the child property as a Hibernate proxy.
The child entity behind the proxy will correctly only be fetched once you access it. The batchSize mapping seems to be ignored here though, so when you actually start accessing the .child entities it will again issue one query per Parent.
Workaround 2: One-to-many and just access the first element
If you really want to keep the FK on the child table and also have lazy loading, you can use this hackaround.
On the Parent.groovy you could specify it like this
static hasMany = [children: Child]
static transients = ['child']
Child getChild() {
children ? children.first() : null
}
static mapping = {
children batchSize: 100
}
Now when you fetch the Parent entities it will correctly ignore the child property, and if you e.g. loop through a list of Parent and access the .child on each, it will only issue one single query for batchSize Parents.
So code like this:
def parents = Parent.list(max: 10)
parents.each {
log.info it.child.subProperty
}
will do the first query to get the 10 parents, and then one single query to lazily batch-fetch the children for up to batchSize parents. With Sql logging enabled it should look something like this:
select child0_.parent_id, child0_.id, ... from child child0_ where child0_.parent_id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
Workaround 3: The eager-fetch non-workaround
If your application code almost always uses the child property, then one option is to give up on lazy fetching and just specify child fetch: 'join' in Parent.groovy.
This will eliminate the N+1 lazy fetching problem, but as a downside Hibernate will now LEFT JOIN the child table and select all it's properties every time you request the Parent entity, even if you never touch the child property.
Workaround 4: Replace hasOne with mapping column: 'id'
class Face {
Nose nose // due to mapping, column 'nose_id' is not required
static mapping = {
nose column: 'id', insertable: false, updateable: false
}
}
class Nose {
static belongsTo = [face: Face] // due to mapping, column 'face_id' is not required
static mapping = {
// use the parent object's ID as this ID
// optional, but clean
id generator: 'foreign', params: [property: 'face']
// reference to the parent object so we don't need an extra column
face column: 'id', insertable: false, updateable: false
}
}

Lua modules inheritance

Need your help with modules inheritance in Lua .
Let's say I've got 2 modules:
The 1st one is "Parent" It defines 1 field called "port" and method "connect" that uses port & domain fields to connect to some service. I wanna define the 2nd field (domain) in Child module, not in Parent one. Or at least to override this field by Child module.
module('Parent', package.seeall)
port = 1234
function connect()
ngx.say("connecting to "..domain..":"..port.."\n")
end
Note that "domain" variable is not defined here!
Now let's see the 2nd one, it's "Child":
local base = _G
module('Child', package.seeall)
local Parent = base.require('Parent')
base.setmetatable(Child, { __index = Parent })
domain = '127.0.0.1'
And here goes main lua code creating Child instance:
local Child = require "Child"
Child.connect()
The problem is that variable defined in Child module is invisible for the method defined in Parent module.. I need to change this behavior to let Parent routines code see variables defined in Child module.. Is that possible?
Can i copy Child's namespace to Parent module somehow?
I'm not particularly familiar with Lua modules, but it seems to me the right solution is to redefine the method as function connect(self) and then access port and domain off of self, which will be the package.
function connect(self)
ngx.say("connecting to "..self.domain..":"..self.port.."\n")
end
-- this could also be written as function Parent:connect()
...
local Child = require "Child"
Child:connect()
That's certainly how I'd do it if I were just setting up regular table inheritance without modules.

NHibernate: How to save a new entity without overwriting the parent:

I'm wondering what the best design would be for persisteing a new child entity with NHibernate without accidentally overwriting the parent in the database.
The problem I have is that the child entity will look something like this:
class Child
{
Parent Parent;
// other fields
}
My problem is that the child has been supplied from the UI layer along with the ID of the parent, and that means that the Parent ref is basically uninitialized: It will have the ID populated but everything else null - because the only way to populate its fields would be an extra round trip to the database to read them.
Now if I call Session.SaveOrUpdate(child) on NHibernate, what's going to happen with the parent. I don't want NHibernate to cascade save the uninitialized parent since that would just destroy the data in the database. How would people approach this problem? Any best practices?
You must use the session.Load(parentid) to get the aggregate root. In contrast to the session.Get() method, this does not actually fetch any data from the database, it just instantiates a Parent proxy object used to add Child objects to the correct Parent in the DB (eg. get the foreign key correctly).
Your code would probably look something like:
// Set the Parent to a nhibernate proxy of the Parent using the ParentId supplied from the UI
childFromUI.Parent = Session.Load<Parent>(childFromUI.Parent.Id);
Session.Save(childFromUI);
This article explains Get/Load and the nhibernate caches really well
You should probably be working with the aggregate root (probably the Parent) when doing Saves (or SaveOrUpdates etc).
Why not just:
Fetch the parent object using the parent id you have in the child from the UI layer
Add the child to the parents 'children' collection
I think you have to overview your mapping configuration for nhibernate. If you have defined on the reference by the child to the parent that hi has to Cascade all, it will update it!
So if you say Cascade.None he will do nothing. All other are bad ideas. Because you allready has the information of this parent. So why read from db agane?!
If your models looks like this
class Parent
{
}
class Child
{
Parent myParent;
}
and you are trying to set the parent and save the child without having a full parent object, just the ID.
You could try this:
session.Lock(child.myParent, LockMode.None);
before saving, this should tell nhibernate that there are no changes to the parent object to persist and it should only look at the object for the Id to persist the association between Parent and Child