🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
Voldenet | my thoughts github.com/FCO/Red/issues/15#issue...1984826416 | 00:18 | |
I'm not sure on `Red-*` methods, it's just an idea | 00:19 | ||
SmokeMachine | looking, thanks! | ||
Voldenet | created-on could use unix timestamp too | ||
in fact, I could add that as a comment too | 00:31 | ||
00:36
jpn joined
00:41
jpn left
01:25
Summer left,
Summer joined
|
|||
Voldenet | defending that `keep model changes instead of model snapshot` approach is going to be hard to defend | 01:28 | |
ngl, it sounds cool, but nothing else | 01:31 | ||
SmokeMachine | Voldenet: I have added there an option to your migration "class"... github.com/FCO/Red/issues/15#issue...1984905771 | 01:49 | |
Voldenet | > User.^migration: *.drop-column("type"); | 01:56 | |
doesn't this require `User` entity to exist? | |||
what if it gets removed in the future? | |||
aruniecrisps | @SmokeMachine you're suggesting that we use a .sqlite file to house the migration plan right? | 02:07 | |
SmokeMachine | That's a reason I'm thinking in not only store the model representation but all model classes to each version | ||
aruniecrisps: not the plan, but the history... | 02:08 | ||
aruniecrisps: but after Voldenet's comment, I'm rethinking it... | |||
aruniecrisps | Yea didn't voldenet suggest using git diffs? | 02:09 | |
Voldenet | well, depends | ||
if we store snapshot, you can use diffs to extract differences | |||
if we store differences in migrations, we have diffs and we reconstruct snapshots | 02:10 | ||
though diffs are not useful in terms of frameworks | |||
tbh. entity framework simply stores whole model in every migration | 02:12 | ||
it gets beyond gigantic | |||
so I'm sure what to avoid | 02:13 | ||
aruniecrisps | What do you think? | 02:14 | |
I wonder what Rails and Phoenix do | |||
SmokeMachine | I think my preferred way is storing all models for each version... that was we can get the difference between models and we are able to use them on migrations... | ||
Voldenet | that could work | 02:15 | |
SmokeMachine | by diff, I don't mean git diff, but something like: Model1.diff: Model2 | ||
something like this: github.com/FCO/Red/blob/3e318994d1...akumod#L68 | 02:16 | ||
(this example uses diff from DB to model...) | |||
aruniecrisps | I'm assuming for that though you would need something like sqlite to store thee full model | 02:17 | |
SmokeMachine | no, file | ||
just copy the model file | 02:18 | ||
aruniecrisps | Doesn't that lead to what voldenet was talking about? | ||
SmokeMachine | what? | 02:19 | |
aruniecrisps | Where if you store the whole model in every migration it gets way out of hand? | ||
Or am I misunderstanding something | |||
Voldenet | Hmm, what if entities were only stored on change and otherwise old versions would be used | 02:20 | |
SmokeMachine | sorry... I didn't get it... | ||
Voldenet | the project gets large if you maintain it long enough | ||
SmokeMachine | Voldenet: | 02:21 | |
> Hmm, what if entities were only stored on change and otherwise old versions would be used | |||
I was thinking about that too... | |||
Voldenet | it would require some per-entity versioning and having the list of entities used in model | 02:22 | |
sounds horrible, but shouldn't be that tough to maintain | |||
aruniecrisps | what would that look like though? | ||
what do you mean by per-entity versioning | 02:23 | ||
SmokeMachine | we just increment the version of a model if it changed on that migration... | ||
s/just/only/ | |||
Voldenet | `/migrations/entities/User/1/entity.raku: model User is rw { … }` | 02:24 | |
and then in the migration `/migrations/1/initial-migration.raku: use User:ver<1>` or something similar | 02:25 | ||
aruniecrisps | ah okay that makes sense | ||
I'm not familiar enough with extended identifiers in Raku to figure how to pull out the version number if needed | 02:26 | ||
SmokeMachine | maybe we could use a custom CompUnit::Repository... | 02:27 | |
02:28
kylese left,
kylese joined
|
|||
SmokeMachine | or maybe just add all of them on META6.json? | 02:28 | |
aruniecrisps | I don't like the second idea | ||
SmokeMachine | why? | 02:29 | |
Voldenet | project shouldn't be referencing other versions | ||
aruniecrisps | wait do you mean by add all of them to META6.json, what field would they go under | ||
what voldenet said, and i feel that is the ability to get unwieldy very quickly | 02:30 | ||
SmokeMachine | provides | ||
maybe the custom CompUnit::Repository then... | |||
Voldenet | consider this: `use lib <entities/User/1 entities/Roles/3 entities/Scores/2>; use User; use Roles…` | 02:31 | |
something like that sounds a bit awful | |||
aruniecrisps | Yea, that's what I'm thinking, I don't think the business logic should be directly referencing version numbers | 02:32 | |
Voldenet | but it's a storage optimization for migrations then | ||
SmokeMachine | maybe return with this old idea: github.com/FCO/Red/issues/7 | 02:33 | |
02:36
Summer left,
Summer joined
|
|||
aruniecrisps | I think this idea might be better | 02:37 | |
What are your thoughts @Voldenet? | |||
Voldenet | sounds nice, the only limit is that it has to be parsed | 02:38 | |
with CompUnit::Repository only specific entities could need to be loaded | 02:39 | ||
so, out of 100 entities in 4 versions, the latest necessary migration may only load 4 files (each 50b in size) instead of one being 20kb in size (I'm assuming 50b per entity) | 02:40 | ||
it's not horrible though | 02:41 | ||
aruniecrisps | So basically @SmokeMachine if i'm getting you correctly the idea is to implement schema as a CompUnit::Repository? | 02:45 | |
SmokeMachine | I'm thinking on something like: `use lib "RedSchema#User:ver<1>#Model2:ver<3>#Model3:ver<5>"` | ||
aruniecrisps | That feels like the same as use lib <entities/User/1 entities/Roles/3 entities/Scores/2> | 02:48 | |
SmokeMachine | but you don't need to know where they are.. | 02:49 | |
but yes... | |||
aruniecrisps | you don't need to know where they are, but they're still referencing version numbers | ||
SmokeMachine | yes, and that's what we need on the migration, right? | 02:50 | |
Voldenet | in normal code there wouldn't be any need for that, so either way it's managable | 02:52 | |
aruniecrisps | @SmokeMachine oh you mean for the migration | 02:53 | |
i thought this use lib "RedSchema#User:ver<1>#Model2:ver<3>#Model3:ver<5> was for the business logic | |||
SmokeMachine | better, we could have a Schema.rakumod inside each migration dir and have: | 02:55 | |
class Schema:ver<2> does RedSchema { has @.models = ( Model1:ver<1>, Model2:ver<3>, Model3:ver<5>) } | |||
and then, when we `use RedSchema` it would import all those Models... | |||
I mean for migration, yes... but this last idea could also be used on normal code (with no versions...) | 02:56 | ||
aruniecrisps | I like this idea | ||
SmokeMachine | RedSchema would be just a simple `sub EXPORT` with the logic to se what models and what versions to load and just return a map with them... | 02:57 | |
(sorry, @.models would be strings... not the types) | 02:58 | ||
the only problem with these ideas is to split files if there are more than 1 model on that... | 02:59 | ||
3am... sorry I need to go now... | 03:00 | ||
Voldenet | productive night either way | ||
4am here | |||
aruniecrisps | See you guys later! | 03:01 | |
SmokeMachine | We need to add that last suggestion on the thread... | 03:02 | |
Voldenet | I've added something | 03:06 | |
basically a very brief summary | |||
03:06
Summer left
03:07
Summer joined
|
|||
SmokeMachine | thnks! I was doing that too... I replaced the class with a sub call (I think that makes more sense)... github.com/FCO/Red/issues/15#issue...1984964871 | 03:07 | |
Voldenet: ^^ | |||
Voldenet | and no thought was lost | 03:09 | |
SmokeMachine | github.com/FCO/Red/issues/15#issue...1984966702 | ||
Thank you very much you 2! | |||
I'm going to sleep | |||
03:15
kylese left,
kylese joined
03:37
Summer left
03:38
Summer joined
04:08
Summer left,
Summer joined
04:39
Summer left,
Summer joined
05:06
MasterDuke joined
05:09
Summer left
05:10
Summer joined
05:40
Summer left,
Summer joined
06:11
Summer left,
Summer joined
06:32
MasterDuke left
06:41
Summer left
06:42
Summer joined
07:11
kst left
07:12
Summer left,
Summer joined
07:17
kst joined
07:34
jpn joined
07:39
jpn left
07:43
Summer left,
Summer joined,
Sgeo left
08:13
Summer left
08:14
Summer joined
08:44
El_Che left,
Summer left,
Summer joined
08:54
merp left
08:59
haxxelotto joined
09:01
merp joined,
jpn joined
09:08
sena_kun joined
09:53
sena_kun left
10:42
ACfromTX left
11:13
hudo__ joined
11:17
hudo_ left
11:20
mark22k left
11:21
mark22k joined
11:23
mark22k left
11:24
mark22k joined
11:26
mark22k left
11:27
mark22k joined
11:33
haxxelotto left
|
|||
dutchie | what's the best way to make ascii-only regexes? | 12:14 | |
i.e. i don't want \w etc to match non-ascii characters. or would it be better just to check my string is ascii separately from whether it matches the regex | 12:15 | ||
lizmat | m: say "aa" ~~ / <:ascii>+ / | 12:36 | |
camelia | 「aa」 | ||
lizmat | m: say "bđź‘Ťa" ~~ / <:ascii>+ / | 12:38 | |
camelia | 「b」 | ||
lizmat | m: say "bđź‘Ťa" ~~ / ^ <:ascii>+ $ / | ||
camelia | Nil | ||
lizmat | m: say "ba" ~~ / ^ <:ascii>+ $ / | ||
camelia | 「ba」 | ||
lizmat | m: say "bđź‘Ťa" ~~ / <-:ascii>+ / | 12:39 | |
camelia | 「👍」 | ||
lizmat | ^^ dutchie | ||
12:53
MasterDuke joined
12:57
jpn left
|
|||
dutchie | ah :ascii, couldn't find that in the docs anywhere | 12:59 | |
lizmat | m: say "bđź‘Ťa".contains( / <-:ascii> /' | 13:20 | |
camelia | ===SORRY!=== Error while compiling <tmp> Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 1) at <tmp>:1 ------> say "b👍a".contains( / <-:ascii> /⏏' expecting any of:… |
||
lizmat | m: say "bđź‘Ťa".contains( / <-:ascii> / | ||
camelia | ===SORRY!=== Error while compiling <tmp> Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 1) at <tmp>:1 ------> say "b👍a".contains( / <-:ascii> /⏏<EOL> |
||
lizmat | m: say "bđź‘Ťa".contains( / <-:ascii> / ) | 13:21 | |
camelia | True | ||
lizmat | m: say "ba".contains( / <-:ascii> / ) | ||
camelia | False | ||
lizmat | that's a quick way to ensure that a string contains any non-ascii grapheme | ||
[Coke] | dutchie - if you could be so kind as to open a raku/doc ticket about what you were trying to find. I just tried to search for :ascii itself and couldn't find it, but someone trying to answer your question wouldn't start with that. (but we should probably have all the regex :classes indexed for search.) | 13:22 | |
If not, no worries | |||
tbrowder__ | hi | 13:32 | |
hi | 13:33 | ||
hi | 13:35 | ||
lizmat | tbrowder__ o/ | 13:36 | |
tbrowder__ | hi, lizmat. i'm still blind to my msgs | 13:37 | |
i'm working on a module that looks for the user to set a certain value by one of three mean: | 13:39 | ||
*means: config file, env var, or CLI. i usually expect the priority for programs to check in order first to last: cli, env var, config. | 13:42 | ||
i would appreciate other opinions as to the best way to do that. maybe POSIX has an answer | 13:43 | ||
13:45
jpn joined
|
|||
tbrowder__ | [Coke]: any problem with a merge of my File::Temp PR? | 13:48 | |
13:59
jpn left
14:13
jpn joined
|
|||
[Coke] | tbrowder__: I only had an issue with the sha items in the changelog, but am fine if they go in. | 14:15 | |
I can't address the "meat" of the changes. | 14:16 | ||
tbrowder__ | ok, thnx, maybe lizmat could take a look when time permits | 14:22 | |
14:22
haxxelotto joined
14:28
xinming left
14:29
xinming joined
15:02
jmcgnh left
15:35
haxxelotto_ joined,
haxxelotto left
15:49
Sgeo joined
16:37
vlad joined
16:48
vlad left,
vlad joined
17:05
El_Che joined
|
|||
_grenzo | From a US/Pacific time point of view, rakoons (raccoons?) are crepuscular | 17:08 | |
17:08
vlad left,
vlad joined
|
|||
jdv | trash pandas? | 17:10 | |
_grenzo | Sure, as long as they use Raku | 17:11 | |
17:51
haxxelotto_ left,
haxxelotto joined
18:11
haxxelotto left
18:21
vlad left
18:47
jpn left
|
|||
antononcube | @grenzo Visual aid: | 19:12 | |
cdn.discordapp.com/attachments/633...80191& | |||
tbrowder__ | hi | 19:30 | |
humbug! | 19:31 | ||
19:34
jpn joined
|
|||
_grenzo | Curious, do images work across the irc bridge? | 19:34 | |
19:38
jpn left
19:39
haxxelotto joined
20:01
abraxxa-home joined
20:02
abraxxa-home left
20:04
abraxxa-home joined
20:27
ericst joined
20:28
jpn joined,
ericst left
20:32
kst left,
jpn left
20:39
kst joined
20:43
jpn joined
20:48
jpn left
20:57
abraxxa-home left
21:23
jpn joined
21:28
jpn left
|
|||
japhb | _grenzo: We get a link to a WebP file on cdn.discordapp.com | 21:42 | |
21:44
jpn joined
21:46
haxxelotto left
21:48
jpn left
22:00
haxxelotto joined
22:08
sena_kun joined
22:11
jmcgnh joined
22:12
MasterDuke left
22:24
ponycat joined
|
|||
ponycat | does raku have an equivalent to this? docs.python.org/3/library/os.path.....path.join | 22:26 | |
antononcube | @ponycat Yes, docs.raku.org/type/IO/Path | 22:29 | |
ponycat | thanks, it looks like the add method is what I was looking for in particular | 22:30 | |
aruniecrisps | @SmokeMachine does .^save return the id of the new record when you're saving a new record? | 22:33 | |
SmokeMachine | No, but you can .^refresh to repopulate your object (if you are using the refresh experimental) | 22:35 | |
(If I remember it well… let me take a look) | 22:36 | ||
Sorry, I was wrong, .^save DOES return stuff: github.com/FCO/Red/blob/master/lib...kumod#L481 | 22:42 | ||
22:44
jpn joined
22:45
MasterDuke joined
|
|||
aruniecrisps | It does return something, question is what does it return :cameliathink: | 22:46 | |
22:49
jpn left
|
|||
SmokeMachine | In Pg we return * | 22:55 | |
For SQLite, I think it doesn’t return anything useful… but I have no access to a computer to be sure now… | 22:57 | ||
But why are you using .^save instead of .^create? | |||
aruniecrisps | @SmokeMachine I'm thinking about a good way of doing validations | 22:58 | |
SmokeMachine | What kind of validation? | 22:59 | |
aruniecrisps | form data validation, checking to see whether or not the form data is good or not | ||
so say i'm trying to check to see whether or not a value that is entered into a field is valid | 23:00 | ||
the way i have it is I just validate this data directly and accumulate the errors to show to the client | |||
if you look at what i'm doing for begumpura you'll see what i mean | |||
SmokeMachine | You could do validations on type `subset Name of Str where 0 < *.chars <= 30; has Name $.name is column{ :type<varchar(30) };` | 23:04 | |
But I think form validations should be done before data gets to the model… | 23:05 | ||
aruniecrisps | That's probably a good call | ||
SmokeMachine | As I do on this HTML::Component example: github.com/FCO/HTML-Component/blob...akumod#L32 | 23:07 | |
And that’s common to a form validation be different to the model validation… | 23:08 | ||
23:08
haxxelotto left
23:09
haxxelotto joined
|
|||
SmokeMachine | aruniecrisps: make sense? | 23:19 | |
23:36
sena_kun left
23:45
jpn joined
23:51
jpn left
|