Class schema does not exist

[ncskrypt]

Just updated to the latest version and added the service provider and can't seem to avoid getting this error bombing the site:

ReflectionException
Class schema does not exist

[CWSpear]

To try and add legitimacy to the problem, I've got this issue, too. Just installed it afresh on a young project and get the exact same error.

[CWSpear]

I tried rolling back to 1.1.0 and it wouldn't install:

 ~/Sites/emsconnect.cam/ [master*] composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for kirkbushell/eloquence 1.1.0 -> satisfiable by kirkbushell/eloquence[1.1.0].
    - kirkbushell/eloquence 1.1.0 requires rhumsaa/uuid 3.0.*@dev -> no matching package found.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

I tried removing vendor/ and composer.lock and ran a fresh composer install and still got the error.

[kirkbushell]

@CWSpear yeah 1.1.0 was broken, due to bad dependency management in the composer.json file. That was resolved, but seems it's not picking up the schema binding for the app. Will try and workout what's going on there, will have a fix soon. Thanks for the report @linxgws!

[kirkbushell]

Right, I've actually removed the custom blueprint code. I thought it was working but not sure what planet I was on at the time... seems custom blueprint methods are (currently) impossible to implement. However, the model code should still work.

Will put out a 1.1.2 release shortly...

[kirkbushell]

Fixed in 1.1.2.

[ncskrypt]

Er.. still getting this.

I have to comment out:

public function boot()
    {
        // $this->app['schema']->blueprintResolver(function($table, $callback) {
        //  return new Blueprint($table, $callback);
        // });

in the Service Provider to keep using it.

[kirkbushell]

Wow that's weird. That's gone in the 1.x branch but the tag doesn't include it? O.o

[kirkbushell]

Try again, sorry all =\

[CWSpear]

Shoot... is this plugin incompatible with Ardent?

It appears to try and override save, which Ardent uses with a different signature that gives this error if your signature doesn't match:

Declaration of Zizaco\Confide\ConfideUser::save() should be compatible with LaravelBook\Ardent\Ardent::save(array $rules = Array, array $customMessages = Array, array $options = Array, Closure $beforeSave = NULL, Closure $afterSave = NULL)

[kirkbushell]

@CWSpear ugh. Is all I have to say about that. lol

I would say no if that's the case. If I'm to be honest - that signature and what it's attempting to do literally screams at me. For one (and I gave a talk about this at laracon eu) - validation should be part of its own domain. Secondly, before/after save events can be hooked into.

[CWSpear]

So... What does that mean for me trying to use Ardent and still have my camelCase???

[kirkbushell]

Basically, just don't use the service provider, and load the camelcase trait by itself.

The service provider is there to overload and redefine the alias on the model, which is necessary for camelcase trait to do its work on pivot models. Without that, you won't get the pivot model camelcased attributes - as it has no way to get into it.

In all honesty - I wouldn't use ardent. The approach it takes stems from the rails world, which bundles yet more logic and code into your models (bad!). Here's the talk I did at Laracon EU regarding validation: http://www.slideshare.net/kirkbushell/comprehensive-validation-with-laravel-4

[CWSpear]

Nice, thanks for the slides!

So we're creating a SPA with a RESTful backend and don't have a lot of extreme validation. I don't necessarily want to take every 2 lines of my current code and exchange it for another files and 20 more lines of code.

But conceptually, and on a more complex-validation-project, it's a good approach.

Also, Ardent brings a lot more that is nice:

• Purging redundant data
• Auto hydrating entities
• Simpler hooks (cuz Eloquent's has also super bugged me!)

I'm usually for simplicity > complexity & over-engineering, even if it is the "right way."

But I digress. I removed the service, even tried auto-dumping and got the same error.

Ok, so I got to this point and was about to start telling you that it's still not working, but was playing around with stuff and found out my last comment with the error about save was totally unrelated in the first place... Service in place and everything appears to be working (just a simple GET test). But wanted to keep the rest of my comment since I worked so hard on writing it... lol.

I'll do more testing tomorrow, but I think on my end, we're good! Thanks so much for working on the fix and sharing your insights on Validation. Also, I learned about the 422 response code! That's a good one. Thanks for that, too =)

[kirkbushell]

@CWSpear no problem at all. 1.1.x has been a bit of a nightmare if I'm to be honest - thanks for your continued patience and help in resolving the issues at hand!

[kirkbushell]

Closing this now as noone has reported any issues since. Thanks everyone!

[CWSpear]

Oh yeah, sorry. This does appear to be fixed for us. Thanks!