luckyframework / lucky_record Goto Github PK

Similar to https://gist.github.com/paulcsmith/5b7ce214219021d9b2f6a350cc90d37a

Make it so types can specify which criteria to use

UserQuery.new.created_at.before(3.days.ago)
UserQuery.new.created_at.after(3.days.ago)
UserQuery.new.created_at.at_or_before(3.days.ago)
UserQuery.new.created_at.at_or_after(3.days.ago)

These are basically just aliases for lt, lte, gt, gte

These should go in the Time criteria: https://github.com/luckyframework/record/blob/master/src/lucky_record/charms/time_extensions.cr#L24

https://www.postgresql.org/docs/9.1/static/citext.html

• validate
• success
• before_save
• etc.

Right now this fails

table :whatever do
end

It should compile or at least give a more helpful error when it fails

, <, >=, <=, etc.

crystal-lang/crystal-db#27

See https://github.com/DatabaseCleaner/database_cleaner/blob/master/lib/database_cleaner/active_record/truncation.rb for inspiration

Default to Model::BaseRows unless ModelRows is defined

https://gitlab.com/Zatherz/magicjson/blob/master/src/magicjson/infect.cr#L3-29 Was really helpful for this

This will be done later once callbacks are changed to macros so that they can be easily included/inherited

Start with

• validate_required
• validate_acceptance_of
• validate_confirmation_of

lucky db.extract_migration User

It should inspect the database and the model schema and generate a migration for it. If it's not sure what to do, it can leave commented out code so the user can decide how to act on it

def change
  # The title field is no longer on `User`. You can remove it or rename it
  # remove_column :users, :title
  # rename_column :users, :title, to: :fill_in_new_column_name
  add_column :users, :body, type: String
end

So if you want to make associations required you could.

class CommentForm < Comment::BaseForm
  create_default_save_method false

  def self.save(params, article : Article)
    new(params).article_id(article.id).save
  end
end

Ideas for how it would look: https://gist.github.com/paulcsmith/0a511ab3db994e7b43ad48b8e3dba4a2

Blocked by: #128

Right now if you have this:

class RegistrationForm < User::BaseForm
  allow email
end

The form name for email is user::base_form:email. It should be registration:email

That way when you load a edit form it will use the values from the record instead of nil

That way it can be used to generate form fields in LuckyWeb

• Better performance
• Better protection against SQL injection

An idea:

posts = PostQuery.new
  # Posts belonging to a specific author
  .author(current_user)
  # Preload comments, and their authors
  .preload_comments(&.preload_author)
  # Just preload the comments
  .preload_comments
  # If you want to do a custom comment query AND preload the authors
  # Works since preload_author is on the query
  .preload_comments(CommentQuery.new.newest_first.not_spam.preload_author)

I think you should be able to call association methods without preloading but in dev/test it will raise if you forget to preload. That way if an N+1 gets to production it won't blow up, but in dev/test you can catch it.

I imagine that in prod you'd want to be able to hook it up to Honeybadger or whatever so that it logs an error though, that way you know an N+1 is happening and needs to be fixed.

I think this is a good balance of catching N+1, not introducing runtime errors, and not having an overly complex method for preloading and getting at your associations.

This will make it a LOT easier to add new operators and fun stuff like "lower"

So you can loop through all the errors

So that if there is something not implemented by LuckyRecord, user's can still do what they need to do when joining, using OR, etc.

Something like:

UserQuery.new.raw_where("users.name = #{PG::EscapeHelper.escape_literal("Paul")}") 

This would likely be done by adding a @raw_where = [] of String to QueryBuilder that gets joined to the regular where clauses. Then adding a raw_where method to Queryable

Note

It will be helpful to add something to the guides that explains this AND explains how to generate a 100% custom query and parse with Lucky::Repo and DB.mapping. That's something that shouldn't require any code changes in LuckyRecord though.

Helpful for use in tests. Do transactions later. They're faster