08:59 <FromGitter> <katafrakt> @Blacksmoke16 If I may share my opinion, my current take (not in Amber, but in general, I code Ruby mostly) is that validation is for data that is entering the system - and it should be ORM-independent. And checking data integrity is fine and very useful - but it should only throw exceptions, not generate fancy error messages to display to end user.

11:56 <FromGitter> <Blacksmoke16> right exactly

11:57 <FromGitter> <Blacksmoke16> what are your thoughts on https://github.com/amberframework/granite/issues/358 ?

11:57 <FromGitter> <Blacksmoke16> @katafrakt ^

14:15 <FromGitter> <wpv1999> wpv1999 09:14 ⏎ I want to know how to set up the framework to do this DNA sequence in comparison with today's datasets can someone join that to me to give me a suggestion or tell me how to pickle say I'm not I am beginner at it http: / /dmb.iasi.cnr.it/camur.php please Let Me Know If someone knows How to set up anything just to load dataset.

14:21 <FromGitter> <Blacksmoke16> i mean thats not really related to this framework at all tho?

14:21 <FromGitter> <Blacksmoke16> more so like "how to load data into a database"?

14:22 <FromGitter> <Blacksmoke16> if anything you could user amber to make a webapp to interact with the data

15:47 <FromGitter> <drujensen> @katafrakt that sounds like a good idea; use exception handling for validations. That would allow the validations to exist anywhere and all be handled in the controller or pipeline.

15:48 <FromGitter> <drujensen> You would still want to collect all the validation errors at once

15:50 <FromGitter> <Blacksmoke16> thats how assert works ^ https://blacksmoke16.github.io/assert/Assert/Exceptions/ValidationError.html

15:50 <FromGitter> <Blacksmoke16> probably should add a getter for the failed assertions on the exception tho

15:52 <FromGitter> <Blacksmoke16> does provide some methods for easily rendering what failed, but the getter would make it so you could do more custom stuff

15:53 <FromGitter> <Blacksmoke16> depends on how you want to implement it

16:38 <FromGitter> <katafrakt> At first using annotation seems weird. I'd need to wrap my head around that. But to clarify, I think those low-lever exception-based validations should fail very rarely and be a sign of something not going well in other parts of the system. Meanwhile the controller/view layer would use other validations, something similar to dry-validations in Ruby (I don't know if such thing exists in Crystal already).

16:48 <FromGitter> <Blacksmoke16> why couldnt they share the same validations?

16:49 <FromGitter> <Blacksmoke16> to me it would make more sense to have the annotation based assertions be at the front of your application, then if it gets past that you know the obj is valid

16:51 <FromGitter> <Blacksmoke16> https://dev.to/blacksmoke16/object-validation-with-assert-25p6 i wrote a blog post on `assert`, are some examples related to how it would work in a kemal api for example

23:29 <FromGitter> <eliasjpr> I incline to have a separate shard for validations, validations can live in any layer. What would be nice for Granite is to be able to understand Database check constraints exceptions this way the data integrity in the database can be enforced and the application will be able@to@understand it. This way there could be app related validation and integrity and data persistence integrity imo they could be related but are

23:29 <FromGitter> ... completely different

23:29 <FromGitter> <eliasjpr> I am not a fan of annotations but I accept that is an approach

23:38 <FromGitter> <Blacksmoke16> Are two types of exceptions that could happen. Business logic validations and database integrity

23:39 <FromGitter> <Blacksmoke16> The database would inherently prevent the latter

23:40 <FromGitter> <Blacksmoke16> If anything I'd be a fan of refactoring granite error handling to make those exceptions easier

23:41 <FromGitter> <Blacksmoke16> Diff exception classes and get rid of the errors array, just leads to hard to debug code since that's not usual behavior