Comments (17)
👍
from rom.
If it's a PITA, it's wrong. Good call, can definitely relate to it.
from rom.
Yeah, theoretically this separation is logical and correct but in practice it's been a pain to deal with those 3 repos from my point of view. Hence I'm starting the discussion.
Thanks for feedback!
from rom.
@solnic I'm agree. As long as we continue to factor out "stable" parts into separate gems/repos (like we did with adamantium, equalizer, anima) (that all had been part of a rom related repo once).
from rom.
@mbj yeah I like that you used the word "stable". it's a key word in this context - ROM is extremely unstable (in terms of API) so keeping things separate so prematurely is a big no-no for me and that's an opinion based on practical experience while working on those projects.
from rom.
@solnic You agree stuff like sql
, equalizer
, adamantium
, anima
, ice_nine
is exactly of the size and "stable"-state it deserves an own repo? - Than we are on the same page.
sql
is special, its under rapid development, but this gem has, by definition, a really narrow interface. So it must not be stable to fulfill the "own repo" requirements.
from rom.
@mbj those are great examples of nice libs that were extracted from a living organism (axiom etc)
Here the story is completely different. We don't know what's ROM. We will define it when we make it work according to our initial expectations (using axiom as the backend, mapping tuples into objects, session with UoW). When that happens it will become clear what we can extract.
There are cases that are very obvious (rarely) where you just know something should be a separate library - SQL is a good example. We need something that generates SQL and holds an AST representation of SQL. Simple, we need a library that will do just that. Re-usability of such library is also obvious.
from rom.
Since you can always generate multiple gems from a single repo, I don't see a downside...
from rom.
@avdi that too :)
from rom.
Yeah, fine with me, a few things tho:
We should have an extraction in mind and not introduce dependencies were they shouldn't be (I'm talking about "inter component" dependencies here). I'm assuming we'd move the relevant code as it is below rom/lib/{mapper, relation, session}
? We should keep it so the separate components are requirable on their own and pass their own "isolated" spec suites (subfolders). I'm already using parts of the stack in an app I'm developing, and I don't need rom-session
so currently I don't require it. I can imagine various scenarios where rom-session
won't be needed. In fact, I can imagine various scenarios where rom-relation
won't be needed but only rom-mapper
will be, which leads me to my next point.
It's funny, now that you mention combining all the repos into one for now, I have the feeling that we should maybe even (prepare to) split one more piece out of the stack: The DSL on top of morpher
that makes it easy to map nested structures using #attribute
, #wrap
and #group
, so basically the DSL currently present in rom-mapper/ducktrap
. Such a thing could then be used by rom-mapper
to integrate the mapping process with the rest of the stack.
I can imagine various usecases for such a gem outside of the rom
stack, in fact, my app could use such a piece already. When my app receives an HTTP
request, there's a dedicated step that takes the various params
coming in with that request (path, query and body params), deserializes them if necessary, and maps them to a Param
object suitable for the specific endpoint that was invoked. Obviously no relations or sessions are involved. It's purely about rejecting structurally invalid input and mapping to a PORO encapsulating all passed in params. Fwiw, validation comes in a later step, so when i talk about structurally invalid, I'm talking about parameter sanitization, the domain morpher
was originally designed for, and shines.
I guess what I'm getting at, is that the current rom-mapper/ducktrap
code could be the initial code for a gem that provides a morpher
DSL targeted for mapping usecases.
from rom.
I'm fine with this as long as we keep following the conventions we've established so far:
- Things not strictly related to the gem are put in
support/
and are decoupled from the rest of the code. They should be allowed to mature to the point where they can be extracted, as time allows. - Make sure dependencies between the primary components are minimized as much as possible and try to isolate the spec suites (as @snusnu recommends).
For the second point, maybe we should have unit tests require just the class under test (and in limited cases required dependencies), and no longer rely on requiring the entire lib all at once in spec_helper.rb
(?). This would allow us to run each unit test in isolation if we wish and naturally minimize dependencies.. and when there are dependencies, they'll be painfully obvious because the specs will have tons of require
statements at the top pointing out the tight coupling.
from rom.
My intention is not to couple everything together, I just want to deal with one Gemfile and one gemspec and one gem push command. I want to keep things logically split in the repo. It's just way easier to work on stuff when you have it in one place. All those things integrate with each other that's why it's gonna simplify the development.
I like the idea of explicit requires in specs. We can try doing that.
from rom.
Throwing this in here half off topic: http://espy.github.io/ubersicht
A dashboard for recent activity on all of a user's or organisation's repos
Regarding the topic, I'm +1 with everything said.
from rom.
Nice, that's almost like something we've been talking about for ages: http://espy.github.io/ubersicht/#rom-rb
from rom.
It'd be awesome if it were possible to add repos that do not belong to the same organization tho. That's what we've been talking about all the time at least
from rom.
@lgierth we centralized issues in this repo some time ago already so it's not...an issue ;)
from rom.
It's done. Closing. Thanks for the input everyone ❤️
from rom.
Related Issues (20)
- Being able to initialise a fully populated ROM::Struct HOT 24
- AutoStruct does not respect type definition when creating HOT 9
- Relation with name `:schema' causes registration problems
- Relax freezing policy for `ROM::Configurable`
- Using Repository#transaction with non-default gateways HOT 2
- Fix Ruby 3.0 compatibility HOT 3
- Running tests raises 'Too many open files - getcwd (Errno::EMFILE)' HOT 1
- Inconsistency between Time formats in ROM::Changeset::PipeRegistry and ROM::Plugins::Command::Timestamps HOT 1
- Relation doesn't work in repository HOT 2
- delete: :by_pk in a repository breaks with timestamps plugin
- Associated entities are not mapped to their entity-classes in case of alias HOT 3
- Error when a relation with the name `options` exists. HOT 2
- Unable to modify the node of a combined assc. when a child of that assc. is combined.
- Aggregate write on self referencing relation not setting foreign key HOT 1
- Batch insert with one INSERT query HOT 7
- Fix multiple association block use to prevent ROM::AssociationSet registry error HOT 1
- Rails 7.1 incompatibility (Object#with) HOT 5
- Broken example code, unexpected auto_struct behavior HOT 3
- uninitialized constant ROM::Memory::Types::Int HOT 3
- Rails 7.1 Upgrade Causes map_with To Throw ArgumentError HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rom.