Support for Laravel's Validator

[qejk]

Hello, thanks for creating this package!

I'm trying to make it work with default Laravel's validator.

Setting up rules for Model like:

'email'    => 'unique:users'

Will of course accomplish nothing, but after setting up 'table' as name of node's label:

'email'    => 'unique:User'

Will actually generate a Cypher query:

MATCH (user:User) WHERE user.email = {email} RETURN *

But because by default Laravel's validator (from: Illuminate\Validation\DatabasePresenceVerifier::getCount()) is trying to run:

return $query->count();

there is a problem with default aggregate() from extended Illuminate\Database\Query\Builder:

ErrorException
Undefined index: aggregate

The problem seems to be with:

$results = $this->get($columns);

That should return array:

array (size=1)
  0 => 
    object(stdClass)[372]
      public 'aggregate' => string '1' (length=1) / 0

And instead of it returns:

Everyman\Neo4j\Query\ResultSet

And at this late moment I've stopped researching...

Thanks!

Are you planning to add Illuminate-Schema like migration support for indexes, unique constraints on labels and CREATE UNIQUE?

http://docs.neo4j.org/chunked/stable/cypher-schema.html
http://docs.neo4j.org/chunked/stable/query-create-unique.html

[Mulkave]

Hi @qejk, thanks for the report. Will be working on the validation/aggregate issue through the weekend and push it as soon as done.

Plans for Schema building are on the list of upcoming features which will be out soon as well.
Will definitely look into the CREATE UNIQUE feature, any suggestions on the usage ? maybe something like createUnique(..) ? or create(..., $unique = true) still not sure.

[qejk]

@Mulkave Thanks! I would go with createUnique() for simplicity. Using true in functions argument's cause many 'remembering' issues for developers... (same go for null's - going back and forward to docs/code just to see "boolean was in second on third argument...?").

I'm half way in doing Illuminate-Schema like Facade, but afais jadell/neo4jphp have few methods for manipulating schema that I would like better to pick instead of running raw Cypher queries.

Atm I have:

• drop
• dropIfExsits

  (there is no dedicated Cypher query, however could do something like MATCH (n:Label) RETURN n LIMIT 1 and then proceed with removing label all done on php side). Personally I don't see this method useful.

• hasLabel
• unique
• index
• dropUnique
• dropIndex
• hasColumn|hasProperty(?) > this is 'yicky', since neo has dynamic-type schema
• dropColumn|dropProperty(?) > ^same

And using Laravel's Schema look-alike client code:

if (Neo4jSchema::hasLabel('User')) {
    // 
}
Neo4jSchema::drop('User');
Neo4jSchema::dropIfExists('User');


Neo4jSchema::label('User', function($label)
{
    $label->unique(['phone', 'username']);
    $label->unique('id');
    $label->index('last_name');
});

Neo4jSchema::connection('neo4j')->label('User', function($label)
{
    $label->dropUnique('id');
    $label->dropUnique(['email']);
    $label->dropIndex(['first_name']);
});

And migrations with dedicated folder labels in migrations|vendor/package/src

Dunno on what stage your up on this feature, would you like contribution or at a sneak peek prehaps? (even for 'raw' copy paste - I dont mind) tests could be done via :schema to pull up constraints/indexes on Labels. (http://stackoverflow.com/questions/19801599/neo4j-is-there-a-cypher-query-syntax-to-list-show-all-indexes-in-db)

However do you have any kind of idea how to handle migrations (db versioning) per say to make them actually... um, useful in neo4j? I'm trying to think few scenarios that could happen when migrating data in neo4j, but many of them are limited by neo itself (like renaming anything in schema) - and how to handle them as nodes (since indexes/unique constraints can be handled easily w/o versioning).

Scenario: Changing label from X to Z

2solve: Rolling back all nodes from Z to X

Other scenarios:
https://github.com/andreasronge/neo4j/wiki/migrations

[Mulkave]

Definitely would be great to have them contributed if you already proceeded with the implementation, I already started setting up for the index/dropIndex methods myself 😛 but since you've worked them out then let's collaborate further, I was thinking of running Cypher straight instead of using the indexing methods provided by neo4jphp.

As for migrations, honestly I wouldn't go so far with them especially with a dynamic db such as Neo4j, though changing labels is a valid scenario that might occur, one thing we can do about it with something like:

MATCH (n:Whiskers)
REMOVE n:Whiskers
SET n:Charlie

or changing relationship labels:

MATCH (a)-[whiskers:CAT]->(b)
DELETE whiskers
CREATE (a)-[sir_hiss:ANACONDA]->(b)

more info in this thread

But then we'll have to be careful for created_at and updated_at properties and in HyperEdges for Polymorphic relations where we set the morph_type where we'll have to move them as well.

[Mulkave]

Aggregates have been implemented and committed in f412bb8 which fixes the validator issue, now moving the Schema discussion to issue #3.

[qejk]

f412bb8 unfortunately the issue with Validator remains, now it prevents from creating any node at all after 1 successful saved model.

[Mulkave]

Weird, can you please provide more details about the code you are trying so that I can track it down ?

[qejk]

Sure, here is simplified to few lines version like most people do validation with Laravel (tried on fresh install even , 4.2):

$users = [
    'bob'   => ['email' => 'bob@test.com'],
    'alice' => ['email' => 'alice@test.com']
];

$rules = [
    'email' => 'unique:User',
];

foreach ($users as $user => $data) {
    $v = Validator::make($data, $rules);

    if ($v->fails()) {
        dd($v->errors());
    } else {
        User::create($data);
    }
}

It will create first node for Bob, but after that validation will fail.

[Mulkave]

Yep got it, sorry for the hassle it turned out to be a bug where the aggregation was not taking the collected query into account. Will fix it asap.