Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aliases' survey #406

Open
FCO opened this issue Nov 10, 2019 · 15 comments
Open

Aliases' survey #406

FCO opened this issue Nov 10, 2019 · 15 comments
Labels

Comments

@FCO
Copy link
Owner

@FCO FCO commented Nov 10, 2019

Hi there!

@Xliff has suggested creating some aliases for .^all.grep and .^all.map, respectlly .^where and .^update.

Remembering that Model.^all represents all Model's database items. And returns a ResultSeq that has (or will have) all Seq's methods to generate SQL queries when needed. And the idea behind Red is that you could use it without needing to learn a lot of ORM's syntax, and use mostly Raku's syntax.

But it's hard for me to believe the users would prefer to learn 2 more meta-method names instead of only knowing 1 (.^all) and using its return as a common Seq.

Another problem is that .^all.map is not used only for updating... it's only an update operation if one change values inside of its block, and calls .save on its return.

So, I'd like to know the other user's opinions on that.

What you guys would prefer?

@FCO

This comment has been minimized.

Copy link
Owner Author

@FCO FCO commented Nov 10, 2019

Create the .^where (.^all.grep) and .^update (.^all.map) as Xliff has suggested

@FCO

This comment has been minimized.

Copy link
Owner Author

@FCO FCO commented Nov 10, 2019

Create new alias, but with different names:

  • .^grep for .^all.grep
  • .^map for .^all.map

That way the user should not learn new names but only that one could use the Seq's method's names directly as meta-method. but on that way, why only grep and map has the meta-method homonymous?

@FCO

This comment has been minimized.

Copy link
Owner Author

@FCO FCO commented Nov 10, 2019

Do not add any alias and let it be the way it is.

@FCO

This comment has been minimized.

Copy link
Owner Author

@FCO FCO commented Nov 10, 2019

If you have any other suggestion, please comment.
and add an 👍 on the option you prefer, please!

@FCO FCO added the survey label Nov 10, 2019
@Xliff

This comment has been minimized.

Copy link
Contributor

@Xliff Xliff commented Nov 10, 2019

I'm fine with 1 or 2. It's not that I don't agree with the way things are spec'd out, I would just like the option to remove the .^all from my code if it becomes repetitive.

@FCO

This comment has been minimized.

Copy link
Owner Author

@FCO FCO commented Nov 10, 2019

if it becomes repetitive, you can always do something like:

my @posts := Post.^all;
@posts.grep: *.published;
@FCO FCO assigned FCO and unassigned FCO Nov 10, 2019
@Xliff

This comment has been minimized.

Copy link
Contributor

@Xliff Xliff commented Nov 10, 2019

That ceases to be a worthwhile solution when you are dealing with a lot of models.

@MattOates

This comment has been minimized.

Copy link
Contributor

@MattOates MattOates commented Nov 10, 2019

I think "where" is an especially bad idea as a name as it will give people too deep an assumption of what is happening wrt SQL. "filter" might be better. The update with the map I don't really like so much. But have the ^map and ^grep with an implicit ^all I think makes sense.

@MasterDuke17

This comment has been minimized.

Copy link
Contributor

@MasterDuke17 MasterDuke17 commented Nov 10, 2019

I'm torn about "where". On one hand it makes sense, but on the other MattOates raises a good point. So yeah, I think "^grep" is good, and a non-updating "^map".

@vrurg

This comment has been minimized.

Copy link
Contributor

@vrurg vrurg commented Nov 11, 2019

Take my third +1 for ^grep and ^map. Entities should not be multiplied without necessity. As these two are perhaps the most used ones, it would probably make sense to shortcut them.

@moritz

This comment has been minimized.

Copy link

@moritz moritz commented Nov 11, 2019

For the record, sqlalchemy requires you to always call .query on a session or a model, which makes it easy to see where the rubber hits the database, so to speak. I kinda like that, so I'm voting against an alias for now.

If you do want to introduce an alias, please go with ^grep instead of something cleverer.

@albertferrico

This comment has been minimized.

Copy link

@albertferrico albertferrico commented Nov 11, 2019

Create new alias, but with different names:

  • .^grep for .^all.grep
  • .^map for .^all.map

That way the user should not learn new names but only that one could use the Seq's method's names directly as meta-method. but on that way, why only grep and map has the meta-method homonymous?

I also think that you can create custom methods, supporting the native ones
for example with ^where, make sense to call it filter_by or something like that

@Scimon

This comment has been minimized.

Copy link

@Scimon Scimon commented Nov 11, 2019

One of the things I like about Red is it feels like writing Raku not SQL. I think if we're going with aliases keeping them Rakuish (.^map and ^.grep) goes with the feel of Red more.

@bazzaar

This comment has been minimized.

Copy link

@bazzaar bazzaar commented Nov 12, 2019

Though the idea of simplifying the syntax, by adding convenience aliases, is possibly a good one, maybe it's a bit early in the development cycle of RED. The module is still in the midst of development, and there isn't much actual usage knowledge yet. Perhaps, it's better not to constrain the developer's thought process with this change. It could be something for the future? Also, I'm not sure that creating 'hybrid syntax' alias names is really the best plan. When querying a database, I'd rather use syntax that is consistent across the entire RED module, and I think we should wait for that to evolve.

@albertferrico

This comment has been minimized.

Copy link

@albertferrico albertferrico commented Nov 12, 2019

Though the idea of simplifying the syntax, by adding convenience aliases, is possibly a good one, maybe it's a bit early in the development cycle of RED. The module is still in the midst of development, and there isn't much actual usage knowledge yet. Perhaps, it's better not to constrain the developer's thought process with this change. It could be something for the future? Also, I'm not sure that creating 'hybrid syntax' alias names is really the best plan. When querying a database, I'd rather use syntax that is consistent across the entire RED module, and I think we should wait for that to evolve.

You made a good point, but I differ from you in one thing. If there are aliases, I think it would be better from a point of view of adoption. I'm very new to raku and if I see an alias rather than actual syntax, maybe I don't feel so frustrated when I try to use the module. I think allowing both (native syntax and aliases) is a good thing to spread the word and make it more user friendly. We need to think that not every developer has a lot of experience in raku, or even, it wouldn't be necessary. Just land on the module page, read a little the docs and start to play with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.