jpdsousa / mongo-obj-framework Goto Github PK

Hacktoberfester?

Hey Hacktoberfester, if you came across this issue and you like MongoDB (and java), you've just found an awesome project to contribute to!

If you're not so much into databases and ORMs but you would like to contribute to other projects of mine: search my other Hacktoberfest issues

Description 🔍

This is actually a simple issue, easily achievable. Just go to the version eye page (or click the version eye badge in the README file), where dependency versions are managed, see which dependencies are outdated and update the pom.xml file with the newest versions.

Note that some dependencies are muted, as they most likely require additional code updates. Feel free to try to update them as well!

Description 🔍

The query API is, at this point, quite simple (only allows match filtering). Thus it needs to support additional MongoDB features.

GridFS refs are not being correctly lazy loaded. As a matter fact, grid refs should not be lazy loaded at all, as they represent explicit references, and can be safely loaded as such.

Description

Partial indexes allow users to filter documents that are added to the index.

Use Cases

• Avoid NULL values to be indexed, since MongoDB only allow one NULL value in unique indexes (source).

Use collection options to allow users to always append a storage time field.

Add the necessary methods to element interface.

Perhaps, add an additional feature to also store last modification's timestamp.

@JPDSousa hi!

What do you think of creating maven hierarchy for this project? It will help to handle resources/testResources automatically by maven. If yes, then I'm ready to change the structure, feel free to assign me to this issue 🙂

Thanks a lot!

Rename test package name so that they match with dev package names.

Separate replace-related operations from update-related operations.

Start by creating different methods in Smof. Then, either use different interfaces or different classes to separate both functionalities.

Description 🔍

At this point, SmofParser relies only in the native parsers provided by the project itself. Providing access to the Mongo Java Driver native Codecs (equivalent to Smof parsers) would be optimal for other features such as querying, updating, inserting, etc.

This will be solved by extending the native IntegerCodec from MongoDB Java driver, allowing it to parse to and from BsonStrings.

When the parser detects an Element, it casts its field to PrimaryField. However, when in an Array of Elements, the Element field is a Secondary field.

CollectionUtils is not being properly tested.

Upgrade update API with the current MongoDB update operators.

At this point, Smof has no mechanism to prevent users to map one type to multiple collections. This should not be allowed.

• Write tests that assert that this is not allowed

Allow users to attach byte arrays to SmofGrifRef, which are then queued to be uploaded to the database.

Support for gt, gte, lt and lteoperators on dates.

Allow users to customize the insertion order between objects and 'sub-objects'. This allows for custom insertions:

• Consider an object A with a field containing B:
  • You want B to be inserted only if A does not exist;
  • You want B to be inserted whether A succeeds or not.

The solution comes in two fold:

• A pre-insert field (boolean) in @SmofObject that allow users to specify if the correspondent object is to be inserted before or after the main object. This is obviously recursive;
• An upsert option in collection options, that if set to false restricts duplicate objects from being inserted twice (i.e. replace). Thus, the insert operation fails, leading to any trailing operations to fail as well (this does not guarantee atomic properties).

SmofTypeContextImpl is iterating through a map to find the (super) TypeStructure of a given type. This presents a considerable performance issue.

Hacktoberfester?

Hey Hacktoberfester, if you came across this issue and you like MongoDB (and java), you've just found an awesome project to contribute to!

If you're not so much into databases and ORMs but you would like to contribute to other projects of mine: search my other Hacktoberfest issues

Description 🔍

Smof is a growing project, with developers who often avoid some design aspects in order to develop and deploy faster (note to self). This issue is focused in fixing such abnormalities, improving the code quality.

How to? 😧

⚠️ Do not panic! Design patterns are not rocket science! ⚠️
This issue is mainly focused in simple design patterns that promote the project's scalability (codewise), such as:

• Adapter pattern: Look for classes that do not implement any interface, and then:
  • Create an Interface with the class name in the same package (might need to rename the class first);
  • The interface adopts the visibility of the class, and implements only its public methods
  • Rename the class <class_name>Impl (e.g. class Collection is renamed to CollectionImpl, creating interface Collection);
  • Change the class visibility type to package. Make the constructor also package and create a create(...) method in the new interface that calls the class constructor. In case multiple case multiple classes implement the interface use the factory pattern (next point);
  • Examples: SmofCollection and SmofCollectionImpl
• Factory Pattern: Look for interfaces that are implemented by multiple classes, and then:
  • Create an additional class with the name <interface_name>Factory that provides methods to create instances from each of the classes;
  • Constructors from each class are set to package;
  • The factory class is implemented through a singleton pattern (i'm naming the singleton method getDefault()).

Questions ❓

Smof has a medium-sized code base at this point, which might lead to an additional effort to find valid code smells (i.e. code that can be improved through the points mentioned above). Feel free to comment in this issue regarding any doubts and suggestions.
❗️ If you detect a situation that might fit into the above points, discuss it here to make sure that it is actually an issue and not a functional requirement. ❗️

Scenario

Consider two Elements:

• A, registered into Smof
  • A references B
• B, not registered into Smof
  Test

A is inserted: how is B serialized?
Expected behaviour: B is serialized as a common object.

Make CollectionUtils factory, where users can design and register their own custom factories.

Provide methods in the Smof pojo to fetch SmofCollections by class.

Hacktoberfester?

Hey Hacktoberfester, if you came across this issue and you like MongoDB (and java), you've just found an awesome project to contribute to!

If you're not so much into this databases but you would like to contribute to other projects of mine: search my other Hacktoberfest issues

Description

Contribute to Smof by writting documentation to the project.

Pro-tips

• Search for classes (mostly interfaces) in packages such as collection, element, field or utils for easy sources of documentation, as the code in these packages is mostly high-level or utils code, which is probably the most straightforward code in the project.
• Get inspired by the official MongoDB Documentation.

Hacktoberfester?

Hey Hacktoberfester, if you came across this issue and you like MongoDB (and java), you've just found an awesome project to contribute to!

If you're not so much into databases and ORMs but you would like to contribute to other projects of mine: search my other Hacktoberfest issues

Description 🔍

Test coverage is really useful in any kind of software project. Smof greatly appreciates test coverage contributions.

How to? 😧

⚠️ Do not panic! Test coverage is not rocket science! ⚠️
Smof uses Maven to run tests. So, in order to run existing tests and create your own:

• Clone the repository;
• Be sure to have maven installed in your machine (check the Maven homepage on how to download and install maven;
• Start a MongoDB instance:
  • mongod --port 20720
  • You can, optionally, specify a path to the database or any other valid options, just make sure the port is set to 27020, which is the port used by Smof to run tests;
• hit mvn clean verify in the projects root folder (i.e. mongo-obj-framework) by default, and wait for the green text stating that everything went fine;
• Now you're good to go. Add tests to the test source folder src/test/java and increase the test coverage!
  • Remember to create test classes that end with Test, such as ExampleTest.java, as Maven Surefire plugin will only run classes with that pattern;
  • Focus on code that is not tested yet. You can resort to the codecov reports, or even to the reports generated by Maven Jacoco Plugin, stored in {project.root}/target/site/jacoco (open the index.html for a sort-of-pretty report).

Questions?

Smof is in active development, and has not been properly tested, which may lead to some occasional bugs or questions. Feel free to create an issue if you stumble upon any bug or comment bellow if you have any douts.

Add methods in a transaction-like fashion to SmofCollections to provide a way to manage bulk-write operations

Do not use ObjectId in AbstractElement.equals(), as the objectID is not a final field, which can lead to (re)hash problems.

SmofGridRef metadata is not loaded when the reference is loaded from the database.

Use bytebuddy to create lazyloading instances of registered classes.

Note: this is already implemented to interfaces.