search

MightyOrm / Mighty

A new, small, dynamic micro-ORM. Highly compatible with Massive, but with many essential new features.
BSD 3-Clause "New" or "Revised" License
101 stars 20 forks source link

Potential next features... #7

Open mikebeaton opened 5 years ago

mikebeaton commented 5 years ago

Short to medium term potential new features:

mikebeaton commented 5 years ago

Varying strongly typed multiple resultsets now working for synchronous QueryMultiple variants on branch ~strongly-typed-multiple (async to follow)~ wip (async now included). Happily without even needing to break the existing documented pattern for reading multiple result sets, which remains supported along with the new methods NextResultSet(), CurrentResultSet and ResultsAs<T>, on the same return objects.

garrjo commented 4 years ago

Firebird - not sure; It is nice when implemented correctly, though...not sure about it.

iSeries? LOL.

mikebeaton commented 4 years ago

I haven't looked at iSeries at all, so I've no idea whether it's fairly standard or not. Firebird definitely did look relatively standard and therefore straightforward.

When you say Firebird is nice when implemented correctly, did you have in mind any particular problems which can result in its not being implemented correctly?

PS I'm most interested in hearing from anybody who's actually using Mighty or Massive, or considering using Mighty, and would actually use Mighty for a new project "if only it supported X"!

garrjo commented 4 years ago

FireBird -> limits on IN / UNIONS / EXISTS statements are generally woefully smaller than most standard SQL Platforms; and as such many developers free form their development as though, they are using standard SQL; I would think you'd need to check block size returns on the Firebird result sets in some manner that would prevent non-return/non-execute...I believe, that the error result from (if in fact it does error is Block limit exceeded...and would need extensive trapping).

I use Mighty all the time now and each day I'm loving it more and more. Massive's limitations on Transactions/Stored Procedures meant dapper or ZEntityFramework; until I found Mighty that is. As of yet, the only problem on implementing MightyOrm (which is being corrected) is knowing what to call when I have X.

iSeries - AS400 is intriguing as an option; but putting together a dbProvider for it could be done pretty easily, so not worth the effort.

On the solutions I have been implementing would be nice to have as stated in the other thread...the feature dealing with table valued functions returning IEnumerable would be nice; though QUERY works effectively with the same options; thought, there may be limitations with this approach especially with regards to arguments - having to rely on String.Format options for argument syntax is cludgy - imho.

garrjo commented 4 years ago

Also, on ODP (Oracle Data Provider) -> I expect to be able to call functions however, the execution is a bit different of course than what we do on SQL standard calls. I do not see documentation on executing ODP Functions - normally under ORACLE we call select [schema].fncSomeFunction(param=>'somevalue') FROM X; not sure how we accomplish similar.

mikebeaton commented 4 years ago

Hi @garrjo - Could you post a new issue for the Oracle issue you mention above?

garrjo commented 4 years ago

Hi @garrjo - Could you post a new issue for the Oracle issue you mention above?

I would; except I realized that the issue was really in reference to ref_cursor. So, not really something plugged in for MightyORM. Though, perhaps, there is a way to extend the option to use cursors response?

mikebeaton commented 4 years ago

You can use cursors in Mighty, of course.

I've realised one source of confusion around here is that in Oracle procedures and functions really are the same - just that a function has a return value. In particular, they can both be called as a stored procedure by the ODBC driver. Whereas in SQL Server only stored procedures can be called directly as a stored procedure.

But it seems like you've resolved the issue in #9 anyway, so great.

garrjo commented 4 years ago

I did; and didn't think to look for cursor options in the docs. That is great news, and will help when using oracle functions. Had I seen this option would have definitely, used it for this process. However, the way it is being down now is pretty great too. I knew functions behaved like SQL Server; the caveats however, seem to be around type definitions of the output parameters. In any event thank you for responding and keeping me on my toes.

mikebeaton commented 4 years ago

Self-assigned for getting strongly typed QueryMultiple out of wip and into release. (Not for Firebird...!)