Massive 3? #302
Comments
|
c.f. #234 where @FransBouma has provided good reasons NOT to support transactions in Massive, and a way to work round this if you need to |
|
Hi @mikebeaton ! Can you pls provided massive version for dot net core, since you are almost done as mentioned in #265 |
|
https://github.com/MikeBeaton/Massive/tree/Massive3 This version of Massive supports:
There is a README. It is compile and link compatible with Massive v2.0. [Edited: No unlinked organisation, sorry.] |
|
What's 'massive3' ? Looks like a fork to split the repository in two (this one and the one at Massive3)? If you wanted to fork this to take over massive, I rather would have liked it if you would have said so. Not cool. |
|
It's a huge bunch of new features. It's entirely comptaible with the existing Massive, because you emphasized the need for that. Everything about what I think it is, is in the README. I offered to work with you on Massive, privately, you told me never to contact you privately and that you didn't want any help with large features as it was quicker to do them yourself than to work with someone else. Since then, I have done all the large features listed, because I want them, and because other people need them. At the moment, the only announcement or publicity about this is precisely this issue. It can go wherever we both want it to go next. |
|
It can go only one way: this repository right here is Massive and you can discuss what you want to add, but if you want to fork it, to split it in two, then you're on your own. You have one problem though: I own the copyright of the code I wrote, not you, and with v2.0 that's about all lines, give or take the method signatures and class declarations. You can fork all you want, but I don't give you permission to use any of the Massive 2.0 code as you own 0.0 of that, I do. Make no mistake, I am very harsh in protecting my work. I will report your repo as stolen code to github if you keep it up like this in its own organisation. I will check within half an hour and if it's not gone I will report it. You can fork Massive on your own account and develop it there, but there's a key difference doing that with what you've done now: developing your own fork as a fork on your account still has ties with its upstream, namely this repository. What you have done is effectively taking my code without ties to an upstream and uploading it as your own to an organisation / account you control. That violates my copyright. And don't make this out like I refused to let you built cool stuff, but that's absolutely not the case. You wanted to talk privately and I refused that because this is an OSS repo and things have to be done in the open. You proposed a lot of things which were not going to end up well, and would take a lot of time to debate, time I didn't have. |
|
I now see you also want to get massive uploaded to nuget. I can assure you, if you do, I'll ask Microsoft to take it down, because it will forever block the official repository (this one) to upload a nuget package for Massive and you don't own the official repository: @robconery officially passed it on to me, not you, to make sure it stays alive. This isn't how OSS works. You have central repositories users look at for getting the official bits. you have forks of these repos (with ties to upstream) where people add new stuff and then give back through PRs. What you've done is take the repository and upload it to a spot where you control it and want to move the train forward in the direction you think is best. That only benefits you, not the users of Massive, nor any other contributors. |
|
Reported. |
|
This repository contains the copyrighted work of all contributors, not only me, but a lot of others too. I can't do anything else but to issue a DMCA takedown on behalf of everyone who has contributed to this repository and have your Massive3 organisation removed. Again, I have no problem with you keeping your Massive fork on your own account with upstream ties to this repository (i.e. https://github.com/MikeBeaton/Massive) and do whatever you want there. That's how this model works: if you want to give back to the main repo, you can, but you don't have to. That's fine. What your 'Massive3' organisation suggests is that that is the official Massive repository. It's not. For that I have to issue the DMCA route. I hate that, to be honest, but it's the right thing to do in this case. |
|
Hi there - since I was tagged above I thought I'd weigh in :). I do have a few thoughts... @FransBouma I completely understand how frustrating this might be. Have to say that @mikebeaton's approach here is more than a little overbearing and unkind - you (and I) have put in a lot of work and hijacking that is ... really quite bullshitty. I might suggest, @mikebeaton, that if you want to do things your way you create your own project. Massive has inspired any number of other toolsets, all of which managed to create their own thing. What you're doing here amounts to a bit of "I know better" hostility and, on a personal level, makes me more than a bit cranky. EDIT: I had a little blurb here trying to stay balanced but then yeah... I saw the org and the new name and... no fucking way. @mikebeaton this is complete shit. |
|
@robconery The fork itself is fine, if he keeps it as a normal github fork. The problem I have is with the 'Massive3' organisation which hosts this new Massive fork as well: it suggests that's the official repository. It's not. A github fork itself has ties to its upstream: users can see 'oh this is a fork of another repo' and whether or not decide to go there. But more importantly: they know the origin of the code: where it came from. For a user IMHO this is very important. What if I add new stuff to Massive and it creates two parallel universes? Which Massive is Massive? the one on some random guy's account (this repo) or the one on the official looking 'Massive3' account? It even has a logo! I agree that taking the DMCA route sucks and if there would have been another way I would have: github said they need a DMCA takedown notice to take down an account so I used that. If Mike wants to write Massive SuperExtraOrdinair in his own repo as a github fork, he can and I don't mind: it's a downstream fork, and people do that all the time, that's github. But the upstream ties are crucial: a user of some code on some repo has to know it's a fork and not the official codebase. An official org like 'Massive3' with a repo that doesn't have any upstream ties is a completely different thing. We'll see what github will do. If they keep it up and @mikebeaton wants to keep it up too, then there's not much else I can do besides ignore it completely and tell @mikebeaton to go fuck himself. It's sad though. He contributed MySQL support which was great and works well. I have no idea why people then all of a sudden think they need to control the universe. |
|
@FransBouma yeah edited the comment above. Sorry for this mate; I'll do what I can to help out. |
|
@robconery thanks man :) I hope this is solved so all parties can agree on its solution, as that's best for Massive's users. Time will tell, I guess ;) |
|
No unlinked organisation any more. Sorry. I did this because I wanted SP support. In fact because I'd already added SP support to my own copy, and thought it was good enough to commit back. You said that my proposed SP support was DB specific, Frans, and that it could never support various other useful features like properly handled nulls, or cursors. Which was a challenge, obviously. Especially because I had specifically intended it NOT to be DB specific, and was sure it could handle nulls. But cursors... hmm... intriguing. Now it does all that. (And that's directly thanks to you pointing out all the things it needed to do - and how - if it wanted to try to be properly good.) As part of that I added MySQL support, as much as anything (in fact, more than anything) to be as sure as possible that I had done my SP, cursor, etc. support right. I also (now) want and need .NET Core support. I think the post by @avinashl3175 in #265, just before I was ready to put up what I'd been doing, correctly captures that Massive will lose market share sooner rather than later without it. (That's in my own, not humble enough, opinion.) My own company is exactly just about to need Massive with .NET Core, or else to switch to something else, for example. Supporting multiple providers at once genuinely made it easier to port to .NET Core, and is pretty obviously a nice feature. And making it all so that you can literally drop it into the Massive v2.0 test suite, and it all runs, without any changes whatsoever required, I think is nice too. And - like a lot of what I've done - a direct response to the feedback you were kind enough to take time to give on the various sub-issues which I raised, Frans. Of course, the whole thing, every part of it, is a big bunch of work - with a lot of careful testing, and a lot of new tests. But it is built on @robconery's original Massive, which is genius, and your repository and all the very useful new features which that brings to Massive, too. It's never going to be anything other than that. But now what, I don't know.
Well, there it is - it does some stuff. Hmm. And sorry, again. |
|
I'm glad the 'Massive3' organisation is now gone so there's no confusion what the official massive repository is for users. As for .NET core, the plan is to wait for netstandard2.0. It will arrive this summer and as many ppl wait for that before moving over to .net core, I don't see a problem to wait too. About nuget, Massive is intended to be distributed as source files, because that encourages people to alter the code to their liking if they want to. A nuget package doesn't. I'll think about it. About you personally, @mikebeaton: trust has been broken. I liked the contribution of the MySQL support, but your move to make your massive fork 'the future' (I read your readme version, I was not amused to say the least) broke my trust in you. I don't see myself merge code from you ever again, sorry. |
|
Hi Frans. You've said your piece, so I might as well say mine. I produced this code in good faith. It has a LOT of good (careful, cleanly coded) new features, and it was a lot of hard work. I announced that I was doing this, in this issue: see the first message! You left it open. So I did it. I said that it was a beta/test/trial version. It still is. Sorry about the comment about 'The Future', but I did (and do) mean a (beta/test/trial) comment (in a beta/test/trial version) about a possible future of Massive. Depending on what you think about the beta/test/trial version which I'm showing to you. But I stuffed up. I pissed you off. Bad Idea. And RobConery. Bad idea. And various users of Massive who also commented in that 'Massive3' repository (deleted, by me), and here, that I stuffed up. Then again... there's a bunch of stuff in here that you said couldn't be done as I was doing it (#281/#293 SPs, #285 add args to TryInvokeMember). I guess that's the stuff that was "not going to end up well". It has been done, that way. It works. It hasn't ended badly (in terms of technically). And another bunch of stuff which has been asked for for 5+ years (SPs), 2-ish years (+) (MySQL) or ~1 years (.NET Core)... but hasn't ever happened. Except now, in a lame languishing branch by me, it has. (And by the way, I have committed back a TON of stuff to the main repo, in completely good faith, as I have been going - just look at the recent commit list.) I offered to work with you on these big new features, which I wanted to contribute to, in this codebase, in completely good faith, but you flat out refused. You said you wanted to do them yourself, and that it took more time than it was worth to let anyone else contribute big new features. You did say that, Frans. You are maintaining Massive extremely well, and of course you made a huge contribution to the codebase when you took it on. Massive is stable and solid. But it is not moving forwards fast, right now. Maybe it doesn't need to. But since the scenery (changes to .NET) is moving fast, it is just right now in time starting to look like it will get left behind - as a live project which people actually use, rather than as a genius point in the history of MicroORMs. It is also not true that all the lines of code are yours (I'm talking about authorship, not copyright, here). It's kind of a crazy claim. And you make it (explicitly or implicitly) several times in comments on various issues here. I know the codebase at different versions very well now, and it's simply not true... I'm sure you touched almost every line, but you simply didn't re-write (all of) it. A lot of the code is still Massive v1.0 code. No more than it could possibly be true that all the lines of code in this beta/test/trial branch are by me. Your approach to all the big new things has been (for some years now): "I'll do them soon, I just have to write the next version of my commercial ORM LLBLGen Pro, but don't worry, it won't be long, I'll soon be back to adding new features to the different, free, open source ORM which I wrote.". But it has been long. And you didn't (write it). You added to it (well - very, very well - of course). Rob Conery gave it to you to maintain and add to. You have done, very successfully. It's yours now. And it's still very, very cool - which is why I wanted to work on it and with it. |
|
I didn't flat out refuse anything other than to go into endless debates about trivial stuff. I simply didn't want to do things the way you thought was the best way forward and I stick to that. You now again try to make yourself some sort of victim of me, the bully maintainer, but that's simply not matching reality.
Which lines are still v1.0? The whole design of the code is different from v1.0!
This is a lie: I not only refactored the codebase into a codebase which shares a lot of code among the supported databases, corrected a ton of things, I also added Async/await support, and added all tests. Where did I miss 'the big new things' ? And where did I say that above statement to justify lack of additions (Which additions btw?) I never stated I wrote Massive, see the readme at the start of the project. I changed a lot of the codebase, if not almost every line, since I took over, but the initial code wasn't mine, it was Rob's. I don't have time for this. Again a long winded story with both praises and backstabs, it's been enough. I don't have to defend myself for pouring my own free time in maintaining this codebase, adding a lot of code to it and refactoring it so it was more maintainable during the years. If I hadn't done all that, Massive would have been gone years ago. I don't need your lies that I didn't do anything to really move it forward or that I flatout refused to work with you despite your tremendous amount of work you apparently put into the code and what not. You try to paint a bad picture of me here and that the future of Massive is at stake and apparently not in good hands at the moment. I'm sorry, but how on earth is that going to make me trust you at all? It's not. |
Let me refer you to one of your PRs which I didn't merge: #277 Please read the reply I made there about statistics. You contributed MySQL support (based on existing code, but still, it works and I was happy with the contribution, as I already said to you). And you contributed a lot of trivial things like line-endings, readme typos, references mismatches etc. Don't come with that 'look at the commit list' crap, as if you made a tremendous amount of contributions. When I saw the PR above, I thought "is this some way to get on the commit list a lot of times to get associated with a highly-starred repo?" and I dismissed the thought. Was I right back then with that thought, Mike? It looks like it, doesn't it? See how it feels, when you trust someone and then that all falls apart? Yeah that. |
|
They weren't just whitespace fixes.
And I offered you stored procedure support, which is not small, and not trivial, but which you declined (because you thought it couldn't be made to fully work cross-db, the way I did it; though I carried on and did it anyway, and basically ... it really does do what you (for not unreasonable reasons) thought it couldn't do). And I have .NET Core support, which I am more than happy to still offer back. The way I have done it, it would be trivial to make it so that the two DataTable methods pop back in when .NET Core/Standard is upgraded. I am sorry for this, it's been a bit of a fiasco. Apologies again, Frans - and Rob. |
|
Do you want me to go over every bullet point?
The stored procedure support you offered wasn't added because of the reasons I gave you. I can't merge stuff that isn't working for all databases, and your offering at the time didn't work for all databases. If you since then made it work for all databases, that's great, but what you offered didn't and you know that. Maintaining a codebase means you have the responsibility that the codebase works for the users who take a dependency on it and it keeps working, it stays on the quality they saw when they took a dependency. That means you have to be very careful what is getting into the codebase: comb through every line. It's not some repo that's used by just me or a co-worker, it's a codebase that's used by many many people. That's not a thing to take lightly and it sadly thus comes with the fact that you have to disappoint people who had the best intentions for reasons which might be unclear or even unfair to them. That's life. Adding .NET core support now is a couple of #if statements and a DbProviderFactory instance pass to the ctor, last time I checked, or use polyfills. The main issue is that the code has to change again for netstandard20 and no-one will use the 1.6 one ever again, but it's still out there. I didn't want that, and therefore will wait for netstandard2.0. For the early adopters of .netcore a bit of a let down perhaps, but again c'est la vie. It's not been a total fiasco, Mike. You said it yourself, you were new to open source, didn't know how to start. I gave you a list of things to look into and you did, Massive received a list of things to commit to before sending in a PR, you contributed some changes and MySQL and overall the Massive codebase got better because of it. The code you wrote in your own repo isn't lost either, it's still there, you wrote that code you added. If your employer / company wants to use that they can. The move with the Massive3 org was a total let down and you shouldn't have done that. OSS is besides about code also about trust: shall I invest time in this person to explain things? Go over the code contributed by this person? Is it worth it to invest time to help this person so the PR / code contributed fits better in the overall picture? If I can't trust a person, it's game over in that department: time is a valuable resource, and investing that in a person I can't trust is a waste of it. I'm sorry too it has ended this way, I really thought things were going well after the MySQL contribution. Alas, things went in a different direction. |
|
Yes. All of that. The Oracle db change was the dynamic property set thing. Small, not completely trivial. The .gitattributes thing was just wrong. Commits from different machines were going in wrong (and had done), because of it. It was hard to figure it out and fix it, because it turns out Git gets very fixed about what the line ending settings are and doesn't like changing them once it thinks it knows what they should be for the project. I didn't say the issues weren't minor, I said they were real minor bugs. Writing clear documentation - even one small bit about something - is not just a matter of sitting at a keyboard for 1 minute - and you know that. I fucked up completely about 'Massive 3' - I guess - I think - I got over excited, sorry. The other bit I have for .NET Core is a new way of sending in a connection string, with Sorry, Frans. Mike |
|
Dear Frans (@FransBouma) and Rob (@robconery) (if I may, and since I've already dragged you in to this), I would love to have one last go at trying to explain what I did, and what I thought I was doing. I really thought that when you saw that Massive could cleanly do: dynamic squareResult = db.ExecuteAsProcedure("square_num", ioParams: new { x = 4 });
Assert.AreEqual(16, squareResult.x);dynamic result = db.ExecuteWithParams("BEGIN :a := 1; END;", outParams: new { a = 0 });
Assert.AreEqual(1, result.a);//this is passing input and output cursors between calls, simply, in Massive
var res1 = db.ExecuteWithParams("begin open :p_rc for select* from emp where deptno = 10; end;", outParams: new { p_rc = new Cursor() }, connection: conn);
db.ExecuteAsProcedure("cursor_in_out.process_cursor", inParams: new { p_cursor = res1.p_rc }, connection: conn);that you'd both think that spoke for itself, and was genuinely cool. And it can also now speak to multiple databases at once. And it supports manually controlled transactions by the user (I'd forgotten to even mention that one, because I've done a ton of work on this). And it drops in and passes the v2.0 test suite with no changes at all required (as well, of course, as it's own test suite with tests of all the new stuff). And it runs on .NET Core, now; and as a user of that you don't have to instantiate and pass in factory objects (even though .NET Core makes it hard not to follow that design pattern), you can pass in connection strings with ProviderName added, and it all just works. I don't want that stuff to just sit in my company's code base. But, even if I can repair bridges with you, which I would really like to, I don't think all that is just a bunch of additions to Massive v2.0, I think it's a new version. But I obviously want it to be Massive. A major advantage of it - as it is - is that anyone using Massive could just start using it. I could go off and write a new MicroORM, which takes all my features, and is either explicit that it is Massive with new stuff - which probably doesn't work very well at all (how can I use the Massive namespace in a differently named project, for example? and if I don't, I lose the whole drop-in for current users which I worked so hard on) - or else which re-writes the core engine, similarly to how it is but not identical. Which would both be a waste, because at the moment there's a new version of Massive sitting there, with a bunch of new, genuinely useful features, which someone already using Massive could just take and use. Could I add one final thing? I did announce that I was working on a v3.0 version (right here, this Issue). I did deliver on that announcement, and I did take down the extra organisation (which I thought of as a way to deliver it, not a way to take over) as soon as you (and everyone else) told me that I was being a complete tit. I don't know if there's a way forward, but I wish there was. |
|
I chose to use Massive because it had (still has) an even nicer interface than its major competitors. But while I was using it, in terms of up-to-date support it was at least arguably lagging. E.g. .NET Core, transactions, full stored procedure support (parameter names and directions), multiple result sets. Adding all that sounds like a different project, but I didn't think it needed to be. I thought it could be added to Massive with a high degree of compatibility. That (arguably) wasn't what was wanted, and I (definitely) went about it the wrong way anyway. Sorry. But in case anyone still wants the lovely interface of Massive, but with a bunch of new features, I did finally finish it, and am planning to support it. |
Dear Frans,
Is there any potential for a new, beta Massive 3.0 branch?
We've been discussing loads of issues which I think could live there:
o Compilation but not link compatible refactoring of method signatures:
- AddParam() to add optional name, direction and type support
- Single() to add columns support (Add columns support to Single overload #289)
- Execute() to add DbConnection support (Query supports DbConnection (hence external transactions) but Execute doesn't #301)
o Transaction support (Query supports DbConnection (hence external transactions) but Execute doesn't #301, Any plans to support transactions? #234)
o .NET 4.5+ support only
- Bring async features into Massive.Shared.cs (as you suggested in Add sp support #281)
- Use slightly simpler .NET 4.5 variant of PropertyInfo.GetValue(), etc.
o MySQL support
o Multiple result set support (new Query variant, to return IEnumerable of IEnumerable-s)
I'd be very happy to work on any and all of these. If you're not really interested - at least not in any of the larger breaking changes or refactorings, I'd also be interested in popping up a v3.0 branch of my own.
Mike
The text was updated successfully, but these errors were encountered: